[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