[Oberon] Should hidden re-imports be able to coexist with identifiers

[Andreas Pirklbauer]

Hi Luca,

Yes, you’re right, it works in oberonc of course.. because your compiler
does not “merge” the module list with the list of identifiers as NW did in
PO2013. You use module tables, just like Griesemer's algorithm.

But now I just realized that the issue described below in fact has a
trival fix also in PO 2013, namely to simply check (in ORB.NewObj
and in ORB.thisObj) whether an object x in the topScope is in
fact a re-imported module - and simply skip it if it is one.

PS: A similar situation occurs, when hidden re-imports clash with
alias names (they shouldn’t clash). With the change below it’s
easy to fix to in ThisModule (see below).

PS2: But the import order restriction would still remain.

Andreas


  PROCEDURE NewObj*(VAR obj: Object; id: ORS.Ident; class: INTEGER);  (*insert new Object with name id*)
    VAR new, x: Object; found: BOOLEAN;
  BEGIN x := topScope; found := FALSE;
    WHILE ~found & (x.next # NIL) DO
      IF ((x.next.class # Mod) OR x.next.rdo) & (x.next.name = id) THEN found := TRUE ELSE x := x.next END
    END ;
    IF x.next = NIL THEN
      NEW(new); new.name := id; new.class := class; new.next := NIL; new.rdo := FALSE; new.dsc := NIL;
      x.next := new; obj := new
    ELSE obj := x.next; ORS.Mark("mult def")
    END
  END NewObj;

  PROCEDURE thisObj*(): Object;
    VAR s, x: Object; found: BOOLEAN;
  BEGIN s := topScope;
    REPEAT x := s.next; found := FALSE;
      WHILE ~found & (x # NIL) DO
        IF ((x.class # Mod) OR x.rdo) & (x.name = ORS.id) THEN found := TRUE ELSE x := x.next END
      END ;
      s := s.dsc
    UNTIL (x # NIL) OR (s = NIL);
    RETURN x
  END thisObj;

  PROCEDURE thisimport*(mod: Object): Object;
    VAR obj: Object;
  BEGIN
    IF mod.rdo & (mod.name[0] # 0X) THEN
      obj := mod.dsc;
      WHILE (obj # NIL) & (obj.name # ORS.id) DO obj := obj.next END
    ELSE obj := NIL
    END ;
    RETURN obj
  END thisimport;

  PROCEDURE ThisModule(name, orgname: ORS.Ident; decl: BOOLEAN; key: LONGINT): Object;
    VAR mod: Module; obj, obj1: Object;
  BEGIN obj1 := topScope; obj := obj1.next;  (*search for module*)
    WHILE (obj # NIL) & (obj(Module).orgname # orgname) DO obj1 := obj; obj := obj1.next END ;
    IF obj = NIL THEN  (*new module, search for alias*)
      obj := topScope.next;
      WHILE (obj # NIL) & (obj.name # name) DO obj := obj.next END ;
      IF (obj # NIL) & decl & obj.rdo THEN ORS.Mark("mult def")
      ELSE (*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
      END
    ELSIF decl THEN (*module already present, explicit import by declaration*)
      IF obj.rdo THEN ORS.Mark("mult def") ELSE ORS.Mark("invalid import order") END
    END ;
    RETURN obj
  END ThisModule;

Andreas

- - - - 
> I agree. The above example works in oberonc <https://github.com/lboasso/oberonc> 
> (once you make use of the import M1 and global variable M0 since unused identifiers
> will be an > error in oberonc). At this point I am more and more convinced that the
> algorithm from* Griesemer R. On the Linearization of Graphs and Writing Symbol
> File* is the best approach while still being relatively simple to implement.
> This corner case and many more are handled and it removes the import order
> limitation of Wirth's compiler. 

- - - - -

> > On Thu, May 13, 2021 at 9:33 AM Andreas Pirklbauer < 
>> andreas_pirklbauer at yahoo.com> wrote: 
> > The following reports a “mult def” error in PO 2013 when compiling M2 
> >
> > MODULE M0; 
> > TYPE T0* = RECORD i: INTEGER END ; 
> > END M0. 
> >
> > MODULE M1; 
> > IMPORT M0; 
> > TYPE T1* = RECORD (M0.T0) j: INTEGER END ; 
> > END M1. 
> >
> > MODULE M2; 
> > IMPORT M1; (*re-imports M0.T0*) 
> > VAR M0: INTEGER; (* <--- "mult def” error message*) 
> > END M2. 
> >
> > In PO2013 this error is reported because the symbol table headed 
> > by topScope *also* contains the re-imported module M0 (which is 
> > a bit unfortunate) -- but ORB.NewObj does not check that fact. 
> >
> > I my mind, M2 should compile with no error message. i.e. hidden 
> > re-imports should be able to coexist with regular identifiers (since 
> > one cannot refer to re-imported objects by name anyway). 
> >
> > Comments? 
> >