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

[Andreas Pirklbauer]

Hi Luca,

Thanks for your comment at: http://github.com/andreaspirklbauer/Oberon-test-module-aliases/issues/1

Based on that, I have now also adapted ORB12 (two-pass solution) and ORB13 (one-pass solution) such that they now detect cyclic imports *at compile time*, but *only* in the case where imported or re-imported types of the involved modules are *also* re-exported at the same time - as is the case in your TestCyclicImport01B for example.

In the case where imported or re-imported types of the involved modules are *not* also re-exported - as is the case in TestCyclicImport01A for example - then ORB12 and ORB13 will currently NOT catch the cyclic import *at compile time*. Instead, the module loader will enter into an endless recursion. This would be an “almost acceptable" solution, if it weren’t for the fact, that the programmer now has to restart the system :-(

But it turns out there is a simple fix for that as well - I will make an update to ORB12 and ORB13 later today - which now detects *all* cyclic imports at compile time. In addition, this fix will make symbol files even more minimal than yours, because it will *only* write module descriptors for those modules out to the symbol file, for which the "regular export” in ORB.Export has not already re-exported at least one type. But that’s a minor detail.. the important observation is that it can also be done within the context of ORB12 and ORB13.

Once that fix is in, we'll have a truly fair basis for comparison between 2 complete solutions:

Solution 1 = your solution which uses local and global module tables, as laid out by Griesemer et al.
Solution 2 = ORB12 or ORB13 which solve the same problem, but without module tables or module anchors

I can’t wait to see what we’ll conclude..

PS: Apart from this little exercise, I repeat my earlier comment that even if we'll now have several solutions that solve the alias problem and also the cyclic module import *in its entirely* and *without* any restrictions whatsover, it is, perhaps, still worth pondering over the possibility of implementing only a subset of it: namely by restricting the set of possible use cases as is done in ORB07.Mod (and in Extended Oberon), which can be implemented in 3 (in words: three!) lines relative to FPGA Oberon. But that’s another discussion.

-ap


    > Hi Andreas,
    >
    > I made an additional comment about cyclic imports at
    >
    > http://github.com/andreaspirklbauer/Oberon-test-module-aliases/issues/1
    >
    > Thank you for exploring alternative implementations!
    > I like the improvements in ORB12.Mod and ORB13.Mod, but they are still
    > quite complex. I think that the use of local and global module tables is
    > still simpler, in addition it should produce smaller symbol files: in FPGA
    > Oberon re-exporting types will always lead to writing the module name (and
    > key).
    > With a global module table the module name (and key) is only written once
    > regardless of how many types we are re-exporting from that module.