[net.lang.mod2] Exporting a Module Identifier

Barry_Cornelius@DURHAM.MAILNET (02/12/86)

The Modula-2 Working Group of the British Standards Institution has been
trying to come to terms with the scope rules of Modula-2.  This paper
discusses one particular problem on which the Working Group is seeking
feedback from the Modula-2 community.
The version of the Modula-2 Report in the 1st and 2nd editions of
Wirth's book "Programming in Modula-2" states:
      If a module identifier is exported, then all identifiers
      occurring in that module's export list are also exported.
However, this sentence has been removed from the version of the Report
that appears in the 3rd edition of Wirth's book.
Consider the following example:
      ...
      PROCEDURE p;
         MODULE n;
            EXPORT m1, m2;
            MODULE m1;
               EXPORT a;
               VAR a : INTEGER;
            END m1;
            MODULE m2;
               EXPORT QUALIFIED b;
               VAR b : INTEGER;
            END m2;
         END n;
      BEGIN
         (* body of p *)
      END p;
      ...
Is it legal to refer to a, b, m1.a and m2.b within the body of procedure
p?  Four proposals have been considered:
                       a         b       m1.a      m2.b
      Proposal 1    illegal   illegal     OK        OK
      Proposal 2      OK        OK        OK        OK
      Proposal 3      OK      illegal     OK        OK
      Proposal 4    illegal   illegal   illegal     OK
Wirth's original definition of the language agrees with either Proposal
2 or Proposal 3 - I'm not sure which.  However, I believe that many
implementations of the language Modula-2 agree with Proposal 3.  The
definition that Wirth gives in the 3rd edition of his book leaves out
the sentence quoted earlier.  In a letter to Jeremy Siegel dated
20th February 1985, Wirth states:
      If a module identifier m is exported, then the identifiers which
      m exports become visible, if qualified by m.
So, proposal 1 agrees with this new definition of the language.
Finally, proposal 4 is taken from a development version of a Modula-2
implementation.
The BSI Modula-2 Working Group is aware that changes to the language may
result in failure of existing programs.  It is reasonably satisfactory
when a language change results in an existing program failing to
compile.  However, it is far from satisfactory if a language change
causes a new meaning for an existing program.
Here is an example of a program whose meaning changes:
      ...
      VAR a : INTEGER;
      PROCEDURE p;
         MODULE n;
            EXPORT m1;
            MODULE m1;
               EXPORT a;
               VAR a : INTEGER;
            END m1;
         END n;
      BEGIN
         a := 27
      END p;
      ...
Suppose this program is currently compiled by a compiler that implements
the scope rules as defined by Proposal 3.  So the programmer is making
use of the fact that the assignment to a within the body of p is a
reference to the variable exported from m1.  Now, suppose a standards
body decides that Proposal 1 should be adopted in the definition of a
Modula-2 standard.  If the programmer decides to switch to a compiler
that complies with the standard, the assignment to a will now be
interpreted as an assignment to the variable a that belongs to the block
that surrounds procedure p.  It may not be obvious to the programmer
that he needs to alter his program.  I agree that this is an extreme
example and it may be that there are very few programs like this in
existence!
However, a decision has to be made in order to produce a Modula-2
Standard.  I guess it is possible to put forward arguments to support
each of these proposals.  Examples:
   o  Proposal 1 should be adopted because this is how Wirth currently
      thinks the language should be defined.
   o  Proposal 3 should be supported because this is the definition
      adopted by a large number of implementations that interpreted the
      original definition of the language.
   o  Proposal 1 should be supported because it is a better definition
      than the others.
The BSI Modula-2 Working Group is interested in the views of the
Modula-2 community.  In particular:
(i)   Do you have any strong opinions on which proposal should be
      adopted?
(ii)  Which proposal is adopted by the Modula-2 implementations that you
      use?
(iii) Do you know of any programs that you use which have a different
      meaning depending on which proposal is adopted,
      i.e., the alteration will not be detected at compile-time?
Please send your comments to me as soon as possible.   Send either to:
      Barry_Cornelius%DURHAM.MAILNET@MIT-MULTICS.ARPA
or to my username at Nottingham University:
      bjc.nott.ac.uk
Barry Cornelius, Computer Science, Durham University, Durham DH1 3LE, England.