[Aldor-l] [Aldor-combinat-devel] parametric types and instantiation

[Ralf Hemmecke]

On 10/26/2006 10:59 AM, Christian Aistleitner wrote:
> Hello,
> 
> On Wed, 25 Oct 2006 13:57:10 +0200, Ralf Hemmecke <ralf at hemmecke.de> wrote:
> 
>>> In OO, you instantiate Dom.In Aldor, you evaluate Dom.
>> But evaluating Dom at 1 and Dom at 2 creates (instantiates) two domains
>> Dom(1) and Dom(2).
> 
> but to me, the difference is, that for parametric types in OO, you want
> Dom( 1 ) to be the same domain no matter where it is used. In Aldor, you  
> do not have this restriction. (We discussed it in a different thread some  
> time ago)
> In Aldor you have this requirement only, if Dom( 1 ) appears in type  
> context.
> Consider the following, tricky piece of code:
> 
> #include "aldor"
> 
> import from String;
> import from TextWriter, Character, MachineInteger;
> 
> 
> Cat: Category == with {
> 	getMagicNumber: () -> MachineInteger;
> };
> 
> Dom( a: MachineInteger ): Cat == add {
> 	stdout << "initializing with " << a << newline;
> 	getMagicNumber(): MachineInteger == {
> 		a;
> 	}
> }
> 
> 
> func( EDom: Cat ): () == {
> 	EEDom: Cat == EDom add;
> 	import from EEDom;
> 	stdout << getMagicNumber() << newline;
> }
> 
> func( Dom( 1 ) );
> func( Dom( 1 ) );
> 
> 
> Dom( 1 ) does not appear in type context directly. Hence it should be  
> instantiated twice. And it is instantiated twice:

Hmmm, I agree that the AUG does not prevent a double instantiation. It 
actually leaves it open when and if at all domain-valued functions are 
evaluated. With that understanding I would agree to

	"Hence it *could* be instantiated twice."

but I hesitate to say it _should_. I don't think the AUG says something 
that forces double instantiation in the case above.

> ____________________________________________
> tmgisi at spencer
> cwd: ~/aldor
> $ LC_ALL=C /opt/aldor/bin/aldor -M no-abbrev -C args=-Wopts=-m32 -Fx -l  
> aldor test.as && ./test
> cc1: note: -fwritable-strings is deprecated; see documentation for details
> cc1: note: -fwritable-strings is deprecated; see documentation for details
> initializing with 1
> 1
> initializing with 1
> 1
> 
> In OO, the output of that example would cause serious troubles. In Aldor,  
> it's perfectly valid.

Yes, I have no problem. The compiler behaves here according to the 
specification. However, your code is really tricky.

On top-level you use Dom(1) twice as function arguments for Dom(1). So 
in that context it should be the same. And interestingly it is. Just add 
two lines

---BEGIN aaa.as
#include "test.as" -- code from above
stdout << getMagicNumber()$Dom(1) << newline;
stdout << getMagicNumber()$Dom(1) << newline;
---END aaa.as

at the end of your program. The output then is:

 >aldor -M no-abbrev -grun -l aldor aaa.as
initializing with 1
1
initializing with 1
1
initializing with 1
1
1

Dom(1) gets instantiated 3 times, not 2 and not 4.
I guess, that is also perfectly OK for Christian.
Maybe the line that triggers the first two instantiations of Dom(1) is

 > 	EEDom: Cat == EDom add;

Here EEDom is basically a copy of Dom(1). Maybe that is the reason why 
Dom(1) is instantiated in each call of "func(Dom(1))".

Ralf