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

[Ralf Hemmecke]

>>> 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.
> 
> That was the important part of my example. The rest is not so important.

>> 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.
> 
> I have not yet made up my mind, whether or not I like that statement. 
> But my aim is to have Aldor keywords allowing to override Aldor's choice 
> of whether or not a function is meant functional or not.
> So I am probably too biased anyways.
> 
>> On top-level you use Dom(1) twice as function arguments for Dom(1). So
>> in that context it should be the same.
> 
> Why? I did not get them into type-context yet. Did I?

Hey Christian, I am amazed. I now believe you are right.

If Dom(1) appears twice as an argument of a function "func" then it is 
not in a type context and *must* be evaluated (actually even without the 
line

      EEDom: Cat == EDom add;

So in the program

---BEGIN aaa.as
#include "aldor"
#include "aldorio"
macro I == MachineInteger;
import from I;
Cat: Category == with {getMagicNumber: () -> I}
Dom(a: I): Cat == add {
	stdout << "initializing with " << a << newline;
	getMagicNumber(): I == a;
}
func(EDom: Cat): () == stdout << getMagicNumber()$EDom << newline;
func(Dom 1);
func(Dom 1);
---END aaa.as

gives (at least on my computer with aldor v1.0.2/3):

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

and is thus *not* behaving according to the AUG. The domain should be 
instantiated twice. When 'func' sees its argument it should already be 
eveluated so the '...$EDom' type context inside 'func' should not 
matter. In fact, where would the AUG say that the above program should 
give no output at all if the above definition of func is replaced by

func(EDom: Cat): () == {}

?

Why shouldn't that program behave the same way as if it were defined with

macro Cat == with {getMagicNumber: () -> I}
macro Dom(a) == add {

?

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

My guess is that the AUG should list function application as introducing 
a type context. So maybe the bug is in the AUG and not in the compiler.

But all stays speculation until someone from aldor.org clarifies the 
situation. Let's see how long it takes until that happens. ;-)

Ralf