Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!boulder!sunybcs!bingvaxu!marge.math.binghamton.edu!sullivan
From: sullivan@marge.math.binghamton.edu (fred sullivan)
Newsgroups: comp.lang.modula2
Subject: Re: Redundant import
Message-ID: <694@bingvaxu.cc.binghamton.edu>
Date: Wed, 9-Sep-87 16:21:36 EDT
Article-I.D.: bingvaxu.694
Posted: Wed Sep  9 16:21:36 1987
Date-Received: Fri, 11-Sep-87 05:13:53 EDT
References: <sunybcs!bingvaxu!marge.math.binghamton.edu!sullivan@ames.arpa> <8709061934.AA10237@cayuga.cs.rochester.edu>
Sender: news@bingvaxu.cc.binghamton.edu
Reply-To: sullivan@marge.math.binghamton.edu (fred sullivan)
Organization: Department of Mathematical Sciences, SUNY-Binghamton
Lines: 46

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