[Aldor-l] export from ...

[Christian Aistleitner]

Hello Ralf,

>>> ---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
>>
>> 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. :-|

assume MachineInteger is implemented the way it is implemented now. Then  
someone implements
   ImprovedIntegerSegment: ( Z: IntegerType ) -> with {...}
, where the “with” part coincides with that of IntegerSegment and gets his  
code accepted into LibAldor.

As ImprovedIntegerSegment is performing seriously better, the  
IntegerSegment export of MachineInteger is modified to an export of  
ImprovedIntegerSegment.

Then your code still uses IntegerSegment. Mine automatically uses  
ImprovedIntegerSegment.

But as I said, which way to go is determined but the semantics of your  
code.
Hopefully, the distinction is now more evident.

By the way, I am well aware that changing the export of MachineInteger  
 from IntegerSegment to ImprovedIntegerSegment changes the specification of  
MachineInteger.

> 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);

Yes, I agree. But after changing MachineInteger's export of IntegerSegment  
to ImprovedIntegerSegment, also the equivalent import statement changes to

   import from MachineInteger, ImprovedIntegerSegment(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".

Yes. That's more or less the bug you described before. I did not try to  
resolve the bug, but wanted to show another workaround.

>> 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.

You are right. I forgot that you do not stick to the “one domain/category  
per file” convention. So when not sticking to the convention, such a  
global import might be too much.

> I rather have
>
>          Rep == MachineInteger; import from Rep;
>
> as the first thing inside the "add {...}".

I guess the difference between my global import and your local import is  
merely a matter of style and taste.

But I like your local import. However, to me, Rep is a really, really bad  
choice for the name of the constant. Just think about a possible merge  
your extension's source with the sources of MachineInteger in LibAldor.

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

Definitely.


Kind regards,
Christian