[Oberon] Module aliases - what is the correct way to handle them

Andreas Pirklbauer andreas_pirklbauer at yahoo.com
Wed Feb 19 09:13:31 CET 2020


Hi Paul,

Thank you (and Luca, Jörg and several others..) very much for your great
input on the import alias feature in the Oberon-07 FPGA RISC compiler!

    > 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).

You’ right. The one edge case I can think of that could still be supported by
the current data structure of FPGA Oberon - which doesn’t multiple aliases
per module - is to re-use a module name *after* it has already been imported
under an alias name, as in:

  MODULE B10;  IMPORT M := M0, M0 := M1;   END B10. 
  MODULE B11;  IMPORT M := M0, M0 := M;  END B11.  (*swaps M & M0*)

PS: Your solution proposed in an earlier post (ORB06) actually allows
these, while my current, more restrictive, solution (ORB08) doesn’t.

But if one wants to support *multiple aliases* per module, FPGA Oberon
just cannot handle it. But supporting it would be simple, e.g. just define:

  primary instance      => mod.lev > 0
  secondary instance  => mod.lev = 0 and mod.dsc points to primary instance

where the primary instance can be a proper module or itself be an alias.
Then, additional aliases just get added as secondary instances, and the
check whether a module entry in the topScope is a secondary instance is:

  IF (mod.dsc # NIL) & (mod.dsc.class = Mod) THEN .. secondary instance ..

See, for example, the modules starting at ORB09.Mod at
http://github.com/andreaspirklbauer/Oberon-test-module-aliases

PS: This small experiment was conducted, just to see what it *would*
take, not to suggest its introduction in a particular compiler.




More information about the Oberon mailing list