[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