Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!ut-sally!husc6!mit-eddie!genrad!decvax!ucbvax!DB0TUI11.BITNET!HABERNOL From: HABERNOL@DB0TUI11.BITNET (Thomas Habernoll) Newsgroups: comp.lang.modula2 Subject: Re: Redundant import Message-ID: <8709061934.AA10237@cayuga.cs.rochester.edu> Date: Sun, 6-Sep-87 15:42:13 EDT Article-I.D.: cayuga.8709061934.AA10237 Posted: Sun Sep 6 15:42:13 1987 Date-Received: Sun, 6-Sep-87 22:36:48 EDT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 80 >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.