Module aliases - what is the correct way to handle them
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.
participants (1)
-
Andreas Pirklbauer