[Oberon] new symbol file

[Felix Friedrich]

Strictly speaking, the necessity to recompile a file is a question of 
conistencies of the information used in object-files and not that of 
symbol files. Symbol files only contain the symbolic structural 
information required for the compiler in order to resolve module 
dependencies. Object files are used when modules are loaded or linked 
together.

In the following I refer to your example with import ("<-" denotes 
"imports")
Display <- M2 <- M3 <- M4

In order to make sure that the change of a module source does not lead 
to inconsistencies after compilation when loading or linking modules, so 
called fingerprinting has been introduced. Basically, a fingerprint is a 
hash value that changes when modifications to a module are critical in 
the sense that imported modules would be affected. For example, a name 
change of a procedure parameter will not affect the fingerprint while 
the modification of an exported data structure usually will. 
Fingerprinting can be performed with varying granularity. With Prof. 
Wirth's compiler you have one fingerprint per module, i.e. indeed when 
you recompile a module, all immediately depending modules have to be 
recompiled. However, if the change of a module has a transient effect on 
further modules is a question of its own fingerprint changing. If, for 
example, Module Display defines a datatype extended or reused for other 
exported datatypes of modules M2, then indeed the fingerprint of M2 will 
change and depending modules of M2 have to be recompiled. This is the 
rare case. Usually, the fingerprint of a module is not affected by the 
modification of the fingerprint of an imported module.

R.B.J. Crellier describes in his Thesis "Separate Compilation and Module 
Extension" 
(http://e-collection.library.ethz.ch/eserv/eth:39386/eth-39386-02.pdf) 
how fine grained fingerprinting can be used in order to avoid 
recompilation even of immediately importing modules when they only refer 
to unchanged information of the imported module. This mechanism is used 
in the compilers currently used at ETH for A2, for example. Here, even 
M2 does not necessarily have to be recompiled when Display changes, 
likewise for M3 and M4.

Hope this helps.
Felix


> From: peasthope at shaw.ca
> Date: Sun, 14 Apr 2013 12:23:53 -0700
>> Is recompilation of all modules importing Display... essential?
> From: chris at cfbsoftware.com
> Date: Mon, 15 Apr 2013 07:46:16 +0930
>> Read section 12.6 'Searching the symbol table, and symbol files' in Wirth's
>> 'Project Oberon' book for a thorough explanation.  You will probably find the answer ...
> It is quite dense but this is my tentative answer.
>
> Consider Display imported by M2 which is imported by M3 which is imported
> by M4.  Any change to the symbol file of Display requires recompilation of M2.
>
> According to the sentence "... a chain reaction can be avoided by making symbol
> files self-contained, ...", recompilation of M2 changes the symbol file of M2.
>
> Therefore M3 must also be recompiled.  Similarly M4 must also be recompiled.
>
> Therefore when the symbol file of Display is changed, recompilation of the whole
> system using Native.Tool is appropriate.
>
> Contradictions invited thanks,                     ... Peter E.
>