baskett@decwrl.UUCP (Forest Baskett) (03/31/84)
>iuvax!cjl Mar 27 15:01:00 1984 > > >SEPARATE COMPILATION and MODULE : > > Module is a tool for logical program abstraction. Mutually dependent >modules are not good program design. Separate compilation is a different >issue which is not explicitly supported in Modula-2. It is hidden under >the definition modules and implementation modules. The non-recursive >restriction on modules precludes the separate compilation of mutually >recursive procedures. The restriction on modules in Modula-2 does NOT preclude the separate compilation of mutually recursive procedures. A DEFINITION MODULE is meant to define the names and types of things that may be needed by other IMPLEMENTATION MODULEs. Thus definition module A can define the name and type of proceudre x while definition module B can define the name and type of procedure y. The implementation of x can call y and the implementation of y can call x provided the implementation modules A and B IMPORT y and x, respectively. The implementation modules can be separately compiled provided some form of the imported definition modules are available at compile time. Separate compilation IS explicitly supported in Modula-2. > So a rationale for relaxing the non-recursive modules would be >for separate compilation of mutually recursive procedures only. >In Modula-2, this means cycles should be allowed among the definition >modules and implementation modules if there is no initialization block >in the implementation module. In addition, program should be well >documented to reflect the use of implementation module for the purpose >of separate compilation, not a logical modularization. > >C.J.Lo, IUPUI >cjl@Indiana@CSNet-Relay Definition modules are not allowed to be mutually recursive in the sense of TYPE definitions only. This restriction could be relaxed by having an additional pass in the compiler if it were felt that mutually recursive TYPES separated by module boundaries was useful. Mutually recursive procedures in implementation modules work provided the initialization block of one module does not call a procedure in another module that depends on its initialization block having been completed. The order in which initialization blocks are executed for implementation modules that mutually import from each other cannot be guaranteed. However, the order of execution of initialization blocks prserves the partial ordering of imports in the module import graph when that directed graph is not cyclic. That is, if A imports from B and B does not import from A, B will be initialized before A (at least it will in our implementation). So, normally, you get the right answer. Forest Baskett Digital Equipment Corporation Western Research Laboratory