[Aldor-l] parametric types and instantiation (was: Re: Should this "parser" work?)

[Gabriel Dos Reis]

"Christian Aistleitner" <tmgisi at gmx.at> writes:

[...]

| > My understanding of it, from working on  programming language that
| > supports both OO and parameterized type is that when you have a
| > parameterized domain definition c
| >
| >
| >    Domain(t : Type) == ...
| >
| > calling Domain with argument, say, Integer, is an instantiation of the
| > Domain with type Integer.
| 
| Bear in mind, that Martin's Atom is _not_ a function. Atom is a plain,
| constant domain.

That is *irrelevant*.

| So your example actually does not really apply.
| There is just one Atom. Not an Atom(0) and Atom(1).

The concept of "instantiation" does not *need* parameters or
functions. What I said above is an example of the notion of
instantiation. 

| Furthermore, I guess you are mixing up concepts of parametrized types
| and  Aldor, at least conceptionally.

I don't think so.

| In Aldor, there are no parametrized types or domains.
| 
|    Dom( Param ): ReturnType == add { ... }
| 
| is effectively _not_ a parametrized domain Dom, but Dom is a
| constant.

It is a constant that denote something to be instantiated, if we must
be quibble.

| Dom  is a function (just like any other function, like
|    add:( Integer, Integer ) -> Integer
| ). However, the function Dom creates domains.
| 
| In OO, you instantiate Dom.
| In Aldor, you evaluate Dom.

I believe it is a myopic view to insist that instantiation is an OO
concept; that view does not help to see that the general principle
going on.

| In OO, instantiation of Dom always carries a (at least conceptional)
| connection to Dom.
| In Aldor the result of Dom( A ) is (hopefully) completely decoupled
| from  Dom and A, just as the result 7 of add( 3, 4 ) is completely
| decoupled  from add, 3, and 4.

The notion of "decoupling" is NOT an evidence of absence of
instantiation.  The result of the activation record instantiated for a
function call f(3) is decoupled from 3.

-- Gaby