[Oberon] Module aliases - what is the correct way to handle them

Joerg joerg.straube at iaeth.ch
Tue Jul 14 01:14:50 CEST 2020


Sorry, August (mixed up your name😩)

Perhaps this pseudo code makes my point even clearer:
   IMPORT Out, Debug := Out;
could be seen as
   CONST
      Out = SYSTEM.Import(“Out.sym“);
      Debug = SYSTEM.Import(“Out.sym“);

br
Jörg

> Am 14.07.2020 um 00:57 schrieb Joerg <joerg.straube at iaeth.ch>:
> 
> Karl
> 
> To better vizualize what „import aliasing“ should be doing in my point of view, I tried to explain it with a kind of pseudo code. It‘s not valid Oberon, only meant to explain the idea:
> 
>   IMPORT Out;
> can be seen as a shortcut of the pseudo code
>   CONST Out = import.Out;
> 
> Likewise
>   IMPORT Debug := Out;
> can be seen as a shortcut of
>   CONST Debug = import.Out;
> 
> Now if you write
>   IMPORT Out, Debug := Out;
> whether the compiler parses it from left or right, the semantics stays the same, namely
>   CONST
>      Out = import.Out;
>      Debug = import.Out;
> 
> I see the LHS and RHS in different scopes.
> 
> br
> Jörg
> 
>>> Am 13.07.2020 um 19:17 schrieb Jörg <joerg.straube at iaeth.ch>:
>>> 
>>> Karl
>>> 
>>> I agree that the import implementation of the compiler in ProjectOberon is too simplistic.
>>> We had this discussion already and Andreas provided a solution for this.
>>> 
>>> Generally speaking, the LHS and RHS of an import alias have nothing to do with each other.
>>> RHS is a name of a sym file, LHS is an identifier to be used in your code.
>>> The import order does/should not matter, as the implementation should look up the LHS and RHS in different name spaces.
>>> 
>>> br
>>> Jörg
>>> 
>>> Am 13.07.20, 18:28 schrieb "Oberon im Auftrag von August Karlstrom" <oberon-bounces at lists.inf.ethz.ch im Auftrag von fusionfile at gmail.com>:
>>> 
>>>>   On 2020-07-13 17:57, Joerg wrote:
>>> Debug output could be coded like this
>>>    IMPORT Out, Debug := Out;
>>> and all your debug output like Debug.Str(“packet sent“) appears on screen.
>>   I don't think we can (or should) rely on the import order; an Oberon 
>>   implementation could choose to import modules from right to left and 
>>   it's not obvious that a module should be allowed to be imported twice.
>> 
>>   -- August
>>   --
>>   Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>>   https://lists.inf.ethz.ch/mailman/listinfo/oberon
>> 
>> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon



More information about the Oberon mailing list