[net.lang.mod2] Circularity Peculiarity

patcl@tekecs.UUCP (Pat Clancy) (02/21/84)

Circular reference is indeed a problem, but it is
most serious for implementation modules.

With an implementation modeled after the ETH compiler,
where definition modules are compiled to produce symbol
files, it is not normally possible to compile circular-referencing
definition modules (which one is compiled first?). It may
be possible to "trick" the compiler by eliminating the
import from DM-B (definition module B) into DM-A, compiling DM-A,
compiling DM-B, then restoring DM-A's import list to include
the import from DM-B and recompiling DM-A. The compiler's
time-stamping mechanism might be smart enough to catch
this; however, the last time I used the ETH compiler (quite
a while back), it did not.  Therefore, circularity can
be achieved, but only if the programmer knows what is
going on (by having gone to all that trouble to circumvent
the rules).

Circular reference into implementation modules can be more
insidious, since the programmer may not realize it is
happening. The language definition does not forbid the
situation where IM-A imports from DM-B, and IM-B imports
from DM-A. Presumably, many compilers will and do support this.
In fact, it would be very costly to detect such circularity, since
it requires simultaneous knowledge about what is going on
in implementation modules which are being
separately compiled. It is much cheaper to allow it, using
some simple mechanism; for example, initializing external
modules in the order that they are referenced on import lists,
after first setting an "already initialized" flag in the current
module (note that this creates problems for stand-alone,
ROM-based code!). The problem is that this allows external
references to be made before the corresponding module has been
initialized.

Pat Clancy
Tektronix