[Oberon] Module aliases - what is the correct way to handle them
Paul Reed
paulreed at paddedcell.com
Tue Feb 18 11:12:20 CET 2020
Dear Andreas, Luca and others,
Thank you very much for sharing your comprehensive analysis of the
import alias feature in the Oberon-07 FPGA RISC compiler (ORB). As
usual, an apparently simple feature leads to some thorny edge cases.
> ORB00.Mod 432 398 +0 (=FPGA Oberon, not a correct nor a full
> solution)
> ORB07.Mod 435 401 +3 (=Extended Oberon, correct, but more
> restrictive)
> ORB12.Mod 475 439 +41 (=two-pass solution, full solution)
> ORB13.Mod 485 451 +53 (=one-pass solution, full solution)
I'm still a bit uncomfortable with your loop which tests both canonical
names and aliases at the same time in your ORB07.Mod suggestion:
WHILE (obj # NIL) & (obj.name # name) & (obj.name # orgname) &
(obj(Module).orgname # orgname) & (obj(Module).orgname # name)
DO ...
and would like to propose the following as a minimum change, which fixes
the current ORB.Mod bug and adds the "mult def" check required to catch
a re-use of an alias:
# WHILE (obj # NIL) & (obj(Module).orgname # orgname) DO obj1 := obj;
obj := obj1.next END;
IF obj = NIL THEN (*new module - search for name/alias*)
+ obj := topScope.next; WHILE (obj # NIL) & (obj.name # name) DO obj
:= obj.next END ;
+ IF obj # NIL THEN ORS.Mark("mult def")
+ ELSE
NEW(mod); mod.class := Mod; mod.rdo := FALSE;
mod.name := name; mod.orgname := orgname; mod.val := key;
mod.lev := nofmod; INC(nofmod); mod.type := noType; mod.dsc :=
NIL; mod.next := NIL;
obj1.next := mod; obj := mod
+ END
ELSE (*module already present*)
IF non THEN ORS.Mark("invalid import order") END
END ;
ie 1 change (#) and four lines added (+) from the current version.
WHILE (obj # NIL) & (obj.name # name) DO obj1 := obj; obj :=
obj1.next END ;
IF obj = NIL THEN (*insert new module*)
NEW(mod); mod.class := Mod; mod.rdo := FALSE;
mod.name := name; mod.orgname := orgname; mod.val := key;
mod.lev := nofmod; INC(nofmod); mod.type := noType; mod.dsc :=
NIL; mod.next := NIL;
obj1.next := mod; obj := mod
ELSE (*module already present*)
IF non THEN ORS.Mark("invalid import order") END
END ;
Thanks to your discussions, we know this doesn't allow the more exotic
combinations and uses of imports and aliases discussed, but supporting
those would presumably require changing the current implementation's
single-alias-to-module mapping (type ORB.Module).
What do you think?
Cheers,
Paul
More information about the Oberon
mailing list