🚀 go-pugleaf

>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.