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

[Joerg]

Another view to look at it might be:

IMPORT M;
  can be seen as a shortcut of
IMPORT M := M;

A module M is a collection of exported objects. The righthand side of := defines WHAT objects to be imported, the lefthand side defines HOW to identify these imported objects.

Obviously, all lefthand sides of an IMPORT must be unique. But whether the righthand sides need to be unique as well is in my point of view not defined in the report.

Let’s first agree on what Oberon-07 should allow and then fix ORB accordingly.

br
Jörg

> Am 16.02.2020 um 11:49 schrieb Joerg <joerg.straube at iaeth.ch>:
> 
> Paul
> 
> I disagree.
> 
> IMPORT Y := M0, M0;
> 
> Why should this be forbidden?
> In Oberon it‘s absolutely fine to have the same object visible under different names. Eg.
> TYPE
>  Name* = ARRAY 32 OF CHAR;
>  GivenName* = Name;
>  Ident* = Name;
> 
> So why should the import above not be supported? The report does only state that the first import of the example makes objects of module M0 visible under name Y. The second import of the example, makes the objects of module M0 visible under the name M0. All objects of module M0 are visible with TWO different names. Perhaps confusing but fine.
> 
> Let‘s assume the following
> IMPORT Warn := Out, Err := Out, Out;
> 
> During debugging the warnings and errors are written out. The normal output anyhow.
> 
> In the final version you might want to write:
> 
> IMPORT Warning := OutStub, Error := OutStub, Out;
> 
> br
> Jörg
> 
>> Am 16.02.2020 um 10:24 schrieb Paul Reed <paulreed at paddedcell.com>:
>> 
>> Hi Andreas,
>> 
>>> I currently (and temporarily!) use
>>> ORB07.Mod, which simply tests all possible combinations of
>>> name/orgname...
>> 
>> My reading of the language report,
>> 
>> https://inf.ethz.ch/personal/wirth/Oberon/Oberon07.Report.pdf, section 11,
>> 
>> ...
>> If the form "M := M1" is used in the import list, an exported object x
>> declared within M1 is referenced in the importing module as M.x.
>> ...
>> 
>> is that what you are doing above is definitely wrong, in the sense that once a module is aliased it's no longer available under its canonical name orgname.  I certainly think it would be confusing if it was.
>> 
>> And for example your M4 in
>> 
>> https://github.com/andreaspirklbauer/Oberon-test-module-aliases/blob/master/Sources/M.Mod
>> 
>> where you have
>> 
>> IMPORT Y := M0, M0;
>> 
>> you originally say shouldn't compile, then later you say it should.  I think it shouldn't, whereas I think M5, where
>> 
>> IMPORT Z := M0, M0 := M1;
>> 
>> is fine.  Well, I wouldn't want anyone to actually write that (!), but I can see why you chose it as an example.
>> 
>> So I'm uncomfortable with your recommended solution of ORB07 because it seems to make this re-import check explicit and added on afterwards, whereas I still don't see what's wrong (forgive me!) with the one-line fix to ORB.ThisModule which I suggested before, which tests orgnames instead of names.
>> 
>> I think your elegant efforts to get rid of the somewhat unfriendly "invalid import order" message are great and much appreciated.  And even in the simple implementation, the message might better be changed to something like "import conflict".
>> 
>> Cheers,
>> Paul
>> --
>> 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