hal@newton.physics.purdue.edu (Hal Chambers) (08/19/87)
In some recent news articles I noticed the following type of constructs: DEFINITION MODULE abc; FROM IO IMPORT Open, Close, File, Read, Write; ... IMPLEMENTATION MODULE abc; FROM IO IMPORT Open, Close, File, Read, Write; ... It is not necessary to repeat the imports in the implementation module since the all declarations of the definition module are automatically known to the implementation module. The implementation module only needs to import names which are to be hidden from the definition module. Hal Chambers
samlb@well.UUCP (Samuel B. Bassett) (08/21/87)
In article <802@newton.physics.purdue.edu> hal@newton.physics.purdue.edu (Hal Chambers) writes: >It is not necessary to repeat the imports in the implementation module >since the all declarations of the definition module are automatically >known to the implementation module. The implementation module only >needs to import names which are to be hidden from the definition module. As a followup, is it then considered a bug about which one is justified in screaming at the compiler writer, when objects imported in the DEFINITION Module are _NOT_ visible when compiling the IMPLEMENTATION Module? e.g. Logitech's Modula-2/86 for MS/PC-DOS. Or is this a matter left to the judgement/ingenuity of the implementor? -- Sam'l Bassett, Semantic Engineer -- My words & ideas are for sale! 34 Oakland Ave., San Anselmo CA 94960; (415) 454-7282 UUCP: {...known world...}!hplabs OR ptsfa OR lll-crg!well!samlb; Compuserve: 71735,1776; WU Easylink ESL 6284-3034; MCI SBassett
alan@pdn.UUCP (Alan Lovejoy) (08/21/87)
In article <802@newton.physics.purdue.edu> hal@newton.physics.purdue.edu.UUCP writes: >It is not necessary to repeat the imports in the implementation module >since the all declarations of the definition module are automatically >known to the implementation module. The implementation module only That depends on your compiler. Some actually require the imports to occur in both the definition and implementation modules. I tend to agree with you that this is rather silly, however. Alan "Don't you have to have a license to IMPORT?" Lovejoy
sullivan@marge.math.binghamton.edu (fred sullivan) (08/26/87)
In article <3785@well.UUCP> samlb@well.UUCP (Samuel B. Bassett) writes: >In article <802@newton.physics.purdue.edu> hal@newton.physics.purdue.edu (Hal Chambers) writes: > >>It is not necessary to repeat the imports in the implementation module >>since the all declarations of the definition module are automatically >>known to the implementation module. The implementation module only >>needs to import names which are to be hidden from the definition module. > > As a followup, is it then considered a bug about which one is >justified in screaming at the compiler writer, when objects imported in the >DEFINITION Module are _NOT_ visible when compiling the IMPLEMENTATION Module? There has been discussion of this in the past, to which I did not contribute. Thus I'll have my say now. I am going to quote from Wirth, second edition. (Sorry, I don't have third edition so I don't know what it says.) Page 164: "Both [implementation modules and definition modules] may contain import lists, and all objects declared in the definition module are available in the corresponding implementation module without explicit import." Thus the only possible question is: Does an import constitute a declaration? I can't find a direct answer to this question, but I can find an indirect answer. Page 159: "Standard identifiers are always imported automatically. As a consequence, standard identifiers can be redeclared in procedures only, but not in modules ..." And how were they declared to begin with? By the automatic IMPORT. I claim it's a bug, and one is completely justified in screaming at the compiler writer. Rumor has it that the Waterloo compiler also behaves this way. Does anyone know the truth? Fred Sullivan Department of Mathematical Sciences State University of New York at Binghamton Binghamton, New York 13903 Email: sullivan@marge.math.binghamton.edu
HABERNOL@DB0TUI11.BITNET (Thomas Habernoll) (09/06/87)
>There has been discussion of this in the past, .... Oh yeah! Next discussion is scheduled January 88 :-) The question was: Is it necessary to repeat IMPORTs in an implementation module which were already done in the corresponding definition module? The answer is YES. First the non-formal reason: The problem with software is usually not the first implementation, but to understand existing software. Although the definition modules in Modula are very valuable as an clean interface description for the development of client modules, they are sometimes boring when you try to understand an existing implementation module (because you have to look into both def and impl module to understand the impl module). To inherit IMPORTs from the definition module will make live even harder. I prefer to see at ONE place in the implementation module the interdependencies with other modules. It's boring enough to look for some declarations into the def part. I don't need another chain of indirect cross references. Some of you will be convinced now. But others will point to the Holy Book, edition 2 or 3. OK, let's go on. > .... I am going to quote from Wirth, >second edition. (Sorry, I don't have third edition so I don't know what it >says.) >Page 164: "Both [implementation modules and definition modules] may contain >import lists, and all objects declared in the definition module are >available in the corresponding implementation module without explicit >import." Well, the crucial question is: Is the import of an object equivalent to a its declaration? Wirth sits smiling in his chair and let us do some guessing. >Page 159: "Standard identifiers are always imported automatically. As a >consequence, standard identifiers can be redeclared in procedures only, but >not in modules ..." >And how were they declared to begin with? By the automatic IMPORT. Got you! Wrongo! The fact that an identifier is not allowed to be redeclared isn't a proof that it's (explicit or implicit) occurence in a particular scope must be a declaration. In other wording it means that you are not allowed to redeclare an object that is already used in the current scope. An example: ... CONST N = 100; PROCEDURE P (); VAR s ARRAY [1..N] OF CHAR; (1) TYPE N = [0..1000] (2) BEGIN ... END P; In (1) we are using the global declared constant N. This is an application (and not a declaration) of an object. But it causes that (2) is an error (You may argue the other way around, then (2) makes it impossible to see the global declared N, and therefore (1) is to be marked as an error). And therefore we must not redeclare e.g. INTEGER in a global module, because there is an automagically inserted line saying "FROM TheSparklingStars IMPORT INTEGER;". Mentioning INTEGER in any way is sufficient to prohibit a redeclaration (even whispering is too loud, the compiler will hear you :-) I agree, the book isn't very clear. But in my understanding of all the funny letters in this book, an IMPORT inherits an object, it makes it visible. That's something what is done automatically for procedures and must be specified for modules because they have a higher fence guarding them against the environment. But by no means they are declarations, they are controlled loopholes in the scope fence only. Thomas Disclaimer: I'm not affiliated with any module or it's IMPORT list. I'm speaking as a (sometimes) satisfied user of Modula-2. I could live with treating IMPORTS as declarations, but I can't find a justification for this in the book. I really hopes that the M2 standard will clarify this.
sullivan@marge.math.binghamton.edu (fred sullivan) (09/09/87)
In article <8709061934.AA10237@cayuga.cs.rochester.edu> HABERNOL@DB0TUI11.BITNET (Thomas Habernoll) writes: >def and impl module to understand the impl module). To inherit >IMPORTs from the definition module will make live even harder. >I prefer to see at ONE place in the implementation module the >interdependencies with other modules. It's boring enough to look >for some declarations into the def part. I don't need another chain >of indirect cross references. But the point is that you do have to look at the definition module anyway because there are some declarations there. It is surely inadvisable to attempt to understand an implementation module without having the definition module at hand. It is also entirely possible that the modules are documented by having an explanation of the function of the procedures in the definition module, and an explanation of the implementation in the implementation module, in which case you have to (boring though it might be) read both to understand what's going on anyway. Now, on to other points. OK, I admit it. I was wrong. Imports are not declarations. What imports do is place the module doing the importing within the scope of the declaration (which exists in the module actually containing the declaration). (Wirth - Vol 3, (yes, I found one), page 146.) Now on page 168, we find "The definition module specifies the names and properties of objects that are relevant to clients, i.e. 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." This certainly suggests that one should not have to declare exported objects in the implementation, and I believe that this includes objects which are imported. The crucial point, however, is the verb "declared" in the last sentence. Is it active or passive? I.e., does it mean objects for which a declaration exists in the definition module or does it mean objects within whose scope the definition is? I think it means the latter. Anyone, it is not clear, and I will write Prof. Wirth and ask his intention. When I get a reply I'll post it. Fred Sullivan Department of Mathematical Sciences State University of New York at Binghamton Binghamton, New York 13903 Email: sullivan@marge.math.binghamton.edu