[Aldor-l] export from ...

[Ralf Hemmecke]

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

In fact, a similar reason was the actual source of the problem.
LibAldor uses IntegerSegment in the export of Integer whereas the 
equivalent in LibAxiom is UniversalSegment. I wanted my code to compile 
against both libraries so I tried to avoid "IntegerSegment" altogether. 
But only after I had sent the message, I discovered the workaround with 
the local constant.

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

Yes, much clearer.

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

Oh, of course. So a better way would be to "extend" IntegerSegment with 
the improved code. But that is not so nice as it might seem.

Suppose I write a new library LibFoo which contains

   extend IntegerSegment ...

with more efficient code.

Of course, nothing in LibAldor is changed. So internally LibAldor code 
uses the old implementation. Only new code benefits from the improved 
improved implementation.

Look at the following,

---BEGIN domainInheritance.as
#include "aldor"
#include "aldorio"
Cat: Category == with {
   coerce: Integer -> %;
   <<: (TextWriter, %) -> TextWriter;
   foo: % -> Integer;
}
DomA: Cat == add {
   Rep == Integer;
   import from Integer;
   coerce(i: Integer): % == per i;
   foo(x: %): Integer == rep x;
   (tw: TextWriter) << (x: %): TextWriter == tw << foo(x);
}

Dom2A: Cat == DomA add {
   Rep == Integer;
   import from Integer;
   foo(x: %): Integer == 2*(rep x);
}

main(): () == {
   import from Integer, DomA, Dom2A;
   stdout << "DomA  " << (2::DomA ) << newline;
   stdout << "Dom2A " << (3::Dom2A) << newline;
}
main();
---END domainInheritance.as

I hope you don't think that
aldor -grun -laldor domainInheritance.as
gives

DomA  2
Dom2A 6

Dom2A inherits << from DomA and thus uses the implementation of 
foo$DomA, so the 6 is actually a 3.

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

Well, I know the constant should have been called "Workaround" instead 
of "Rep". And I only can think about a merge with a free and OpenSource 
licence of Aldor. But I have no idea when this will happen or whether it 
will happen at all.

Ralf