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

Paul Reed paulreed at paddedcell.com
Sun Feb 16 10:23:46 CET 2020


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


More information about the Oberon mailing list