[Aldor-l] export from ...

[Ralf Hemmecke]

Hello Christian,

On 12/08/2006 12:33 PM, Christian Aistleitner wrote:
> Hello,
> 
> hopefully this mail is not too off-topic, as I do not discuss the real 
> problem, but present a second workaround.
> 
> On Thu, 07 Dec 2006 22:07:27 +0100, Ralf Hemmecke <ralf at hemmecke.de> wrote:
> 
>> Via
>>
>> aldor -gloop
>> #include "aldor"
>> MachineInteger
>>
>> one finds among the export of MachineInteger a line
>>
>>          export to IntegerSegment(%)
> 
> Just because of one of your previous mails—within the aldor sources of 
> MachineInteger, there is no “export to” but “export from”.
> However, you are correct, my interpreter also prints out the “export to”.
> 
>> ---BEGIN aaa.as
>> #include "aldor"
>> extend MachineInteger: with {elements: () -> Generator %} == add {
>> #if WITHSEGMENT
>>     import from IntegerSegment %;
>> #endif
>>          elements(): Generator % == generate {
>>                  for i: MachineInteger in 1 .. repeat yield i;
>>          }
>> }
>> ---END aaa.as
>>
>> woodpecker:~/scratch>aldor -DWITHSEGMENT aaa.as
>> woodpecker:~/scratch>aldor aaa.as
>> "aaa.as", line 7:
>>                  for i: MachineInteger in 1 .. repeat yield i;
>> ...........................................^
>> [L7 C44] #1 (Error) There are no suitable meanings for the operator `..'.
>>
>> I would have expected that "import from IntegerSegment" were unnecessary
>> in that case.
> 
> Assuming your example demonstrates a bug, I assume it is treated like 
> any bug reported to Aldor.org. Therefore, we need workarounds. Let me 
> suggest another workaround, because your approach actually uses (or may 
> be interpreted in a way to use) part of the implementation details of 
> MachineInteger.
> 
> Assume by “1 ..” you acutally mean an element of IntegerSegment( 
> MachineInteger ), I'd consider your code nice and expressive.
> 
> But maybe by “1 ..” you actually mean calling the function „..: 
> MachineInteger -> IntegerSegment( MachineInteger )” supplied in some way 
> (export from) by MachineInteger. (Note the subtle difference to the 
> previous case.) Then your code would exploit knowledge that 
> MachineInteger provides the “..” via “IntegerSegment( MachineInteger )” 
> itself.
> 
> The difference is hard to see, as it actually is only a semantic one.

It is not hard to see, it is invisible to me. :-|
If I am not completely wrong, then the

   export from IntegerSegment %

appearing in the exports of MachineInteger just says that later

   import from MachineInteger;

is equivalent to

   import from MachineInteger, IntegerSegment(MachineInteger);

But inside the add of and "extend" there seems to be not silent import 
of that kind. And even making it explicit, the compiler tells me that it 
ignores "import from MachineInteger".

> However, for the second case, let me suggest importing from the domain 
> you want to extend. In your case, this comes down to
> 
>   #include "aldor"
> 
>   import from MachineInteger;
> 
>   extend MachineInteger: with {
>           elements: () -> Generator %;
>   } == add {
>            elements(): Generator % == generate {
>                    for i: MachineInteger in 1 .. repeat yield i;
>            }
>   }
> 
> 
> . Because of the import, you bring all functions of MachineInteger into 
> scope. Especially also those from “export from” statements. Therefore, 
> you now use the “..” function with the semantics as shown in the second 
> case above.

Ah. That is yet another way to the one I found. The problem with your 
import is that it is global and migth interfere with some other code 
where I don't want to see the exports of MachineInteger.

I rather have

         Rep == MachineInteger; import from Rep;

as the first thing inside the "add {...}". Interestingly, one needs an 
extra constant.

But still, it would be helpful to know, what the language specification 
says.

Ralf