[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