[Oberon] Module aliases - what is the correct way to handle them
Andreas Pirklbauer
andreas_pirklbauer at yahoo.com
Mon Feb 17 13:46:47 CET 2020
> In addition, this fix (in ORB12 and ORB13) will make symbol files even
> more minimal than oberonc, 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.
Actually, this is not necessarily the case. In modules with many re-imported
types, oberonc ends up better in fact, because - as Luca has pointed out
earlier - the global module table used in oberonc ensures that the module
name (and key) is only ever written once, regardless of how many types
we are re-exporting from that module.
In any case, here are some stats:
Variant Lines sloc Difference in sloc relative to FPGA Oberon (projectoberon.com)
ORB00.Mod 432 398 +0 (=FPGA Oberon, not a correct nor a full solution)
ORB07.Mod 435 401 +3 (=Extended Oberon, correct, but more restrictive)
ORB12.Mod 475 439 +41 (=two-pass solution, full solution)
ORB13.Mod 485 451 +53 (=one-pass solution, full solution)
oberonc: >100 ? (guessing from the diff file, but hard to compare due to other differences)
More information about the Oberon
mailing list