[Oberon] IMPORT Modules: why does order matter?
joerg.straube at iaeth.ch
Sun Mar 3 22:49:07 CET 2019
Chapter 12.6.2 of this document https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.Applications.pdf
„Objects exported from some module M1 may refer in their declaration to some other module M0 imported by M1. It would be unacceptable, if an import of M1 would then also require the import of M0, i.e. imply the automatic reading of M01's symbol file. It would trigger a chain reaction of imports that must be avoided. Fortunately, such a chain reaction can be avoided by making symbol files self-contained, i.e. by including in every symbol file the description of entities that stem from other modules.“
So when importing M1 (that reuses types of M0) the nessecary elements of M0 are included (re-exported) in the symbol file of M1. By doing so, the compiler does not need to import the complete M0.
But if you LATER import M0, these objects being previously imported by M1 would have to be merged to the orginal elements of M0. If you don‘t merge, the symbol table would have TWO different entries of the same type. (The type M0.T re-exported by M1 and the original M0.T in symbol file M0). Two different entires for the same type result in type incompatibilty. Merge is complicated but can be done but for simplicity reasons, an error is thrown.
> Am 03.03.2019 um 22:19 schrieb Peter Matthias <PeterMatthias at web.de>:
>> Am 03.03.19 um 21:49 schrieb Till Oliver Knoll:
>> Again, I do take it that there*must* be some technical reason for this,
>> at least that it simplifies the compiler itself. But I still don't quite
>> get it what the compiler is trying to tell me here... and yes, the above
>> ModuleClient compiles perfectly once we switch the import order, so:
>> IMPORT ModuleA, ModuleB; (* much better now - compiles *)
> My wild guess:
> It's easier to check symbol file consistency this way. Imagine ModuleB
> also imports ModuleA0, ModuleA1... compiler has to store all imported
> symbol files' checksums of ModuleB if it would be allowed to import
> ModuleA after ModuleB. If ModuleA is imported first, compiler already
> knows needed symbol file.
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Oberon