dcw@icdoc.UUCP (05/22/87)
Here is the entire paragraph from PIM2 ed3, p168 which is causing so much discussion : upper case indicates italics present in ed3, whereas << >> indicates my highlights. "The DEFINITION MODULE specifies the names and properties of objects that are relevent to clients, ie. other modules which import from it. The IMPLEMENTATION MODULE contains local objects and statements that need not be known to a client. In particular the definition module contains constant, type and variable declarations, and specifications of procedure headings. The corresponding implementation module contains the complete procedure declarations, and possibly further declarations of objects not exported. Definition and implementation modules exist in pairs. Both may contain import lists, and <<all objects declared in the definition module are available in the corresponding implementation module without explicit import>>" The dispute [about whether objects imported in a definition module are automatically "inherited" into the corresponding implementation module] therefore hinges on the meaning you attribute to the highlighted phrase in that last sentence : Specifically, Is an import a DECLARATION ? My opinion, for what it is worth (very little!!) is that an import is NOT a declaration. In other words, I agree with Thomas Habernoll, who says: >.... An import is a way to extend >the scope of a declaration, and therefore makes the declared identifier >visible in the importing module. But it don't move the location of >the declaration. That is, the DECLARATION of these imported objects are in the definition module which exports those objects, and is not DUPLICATED in any module [defn OR impln] which uses those objects. On the other hand, Gernot Heiser [of ETH Zurich, no less!] says : >Imports ARE declarations! PIM2 ed2 p 143 (sorry, I don't have ed3 at hand, >but there should be no difference concerning this point): >"Every identifier occuring in a program must be introduced by a declaration, >unless it is a standard identifier." >This means, importing an identifier into a definition module declares this >identifier, and hence makes it "available in the corresponding implementation >module without explicit import." (PIM ed2 p 164) I disagree, for the reasons given above. One last thought : could Prof. Wirth contribute directly to this discussion? It's "his" language, Standards Committees notwithstanding :-) This discussion has only arisen because various compiler writers obviously interpreted his specification of the language in different ways, thus writing incompatible compilers. Had he made the description unambiguous in the first place [an impossible task, of course: let me rephrase it as "less ambiguous"], the compiler writers would have had no excuse for getting it wrong... Ah well, I guess I'll just have to wait for Edition 4 ????? It might even be well written, this time... [sorry, snide comment, it's late] Duncan. ----------------------------------------------------------------------------- JANET address : dcw@uk.ac.ic.doc| Snail Mail : Duncan White, --------------------------------| Dept of Computing, This space intentionally | Imperial College, left blank...... | 180 Queen's Gate, (paradoxical excerpt from | South Kensington, IBM manuals) | London SW7 ---------------------------------------------------------------------------- Tel: UK 01-589-5111 x 4991/4982 ----------------------------------------------------------------------------
randy@oresoft.UUCP (Randy Bush) (05/23/87)
In article <443@ivax.doc.ic.ac.uk> dcw@doc.ic.ac.uk (Duncan C White) writes: >One last thought : could Prof. Wirth contribute directly to this discussion? >It's "his" language, Standards Committees notwithstanding :-) Maybe we can get a hint to Professor Wirth's intent by looking at 'his' compilers (before hacking by others outside of his group). If memory serves me correctly, they do not consider a definition module's importees to be imported into the corresponding implementation. I must warn that my opinion is suspect, as I participate in the standardization (see, we can't even agree on how to spell it!) efforts. :-) -- Randy Bush, Compiler Group, Oregon Software, Portland Oregon (503) 245-2202 uucp: ..!tektronix!oresoft!randy Telemail: RBush Fidonet: 1:105/6.6