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