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

[Andreas Pirklbauer]

> […] A similar situation occurs, when hidden re-imports clash with alias names.

Thanks to all for the various emails on this topic. Below is a fix for this topic as
well: One simply skips re-imports (~obj.rdo) in NewObj, thisObj *and* now also
in ThisModule, and simultaneously allows re-imports and aliases to co-exist:

  PROCEDURE NewObj*(VAR obj: Object; id: ORS.Ident; class: INTEGER);  (*insert new Object with name id*)
    VAR new, x: Object;
  BEGIN x := topScope;
    WHILE (x.next # NIL) & ((x.next.name # id) OR (x.next.class = Mod) & ~x.next.rdo) DO x := x.next 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;
  BEGIN s := topScope;
    REPEAT x := s.next;
      WHILE (x # NIL) & ((x.name # ORS.id) OR (x.class = Mod) & ~x.rdo) DO x := x.next END ;
      s := s.dsc
    UNTIL (x # NIL) OR (s = NIL);
    RETURN x
  END thisObj;

  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) OR decl & ~obj.rdo) DO obj := obj.next END ;
      IF (obj # NIL) & obj.rdo & decl 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;

With that fix, the only remaining restriction in the PO 2013 compiler relative to
Luca’s ‘oberonc’ compiler is the "invalid import order” restruction.

And that one is also doable, but would be a tick more complex (merging of lists
of type objects in mod.dsc). Worth the trouble?

-ap

- - - - 

> 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? 
> >