[Aldor-l] local vs. non-local

[Christian Aistleitner]

Hello,

your point was that the following piece of code

> ---BEGIN aaa.as
> #include "aldor"
>
> DomA: with {
> 	new: () -> %
> } == add {
> 	Rep == Record(abc: Integer);
> 	import from Rep;
> 	new(): % == per [0];
> }
>
> DomB: with == add {
> 	Rep == Integer;
> 	local foo: DomA == new() $ DomA;
> 	local new(x: Integer): % == per x;
> }
> ---END aaa.as

does not work, because of the "local" modifier in DomB's "local new" line.

On Mon, 26 Feb 2007 18:25:41 +0100, Ralf Hemmecke <ralf at hemmecke.de> wrote:

> Perhaps I could understand that the compiler complains about two "new"
> functions inside DomB where one of them is local and the other is not.

If you meant something like
   local funcA():() ==
   funcA():() ==
then it would be obviously wrong, as you'd redefine the constant funcA of  
type () -> (). If statement referred to constants with different types,  
read on ;)

> But even then it would be strange to think that there is a good reason
> why the compiler should forbid something like
>
> baz(i: Integer): % == ...
> local baz(): % == ...
>
> because the two functions have different types.

Aldor (the language--according to the AUG) allows to overload constants  
bearing the same name but different type. The modifier local does not  
forbid this:

#include "aldor"

Dom: with == add {
         local new(x: Integer): () == {};
         new(x: Integer, y: Integer): () == {};
}

This style of code can also be found in the Aldor library (compare
   sort!(l:%, less:(T, T) -> Boolean):%    == ...
   local sort!(l:%, n:Z, less:(T, T) -> Boolean):% == ...
of List). Therefore, I assume it is strongly supported by Aldor.

> Does there anybody know what happens here? Is this a compiler bug?

I do not know. Looks like the new()$DomA is messing up the DomB's "add"  
scope, by introducing the symbol "new". However, it should not.
Switching the two local lines of DomB makes the code work. (Thereby, the  
line "local new" introduces the symbol "new".)
To underpin this, one can convert foo into a function (hence the right  
hand side of foo's == gets its own scope). This solves the problem as well.

Kind regards,
Christian