🚀 go-pugleaf

In article <8705151536.AA07897@bugs.nosc.mil> broman@BUGS.NOSC.MIL (Vincent
Broman) writes:
>Said heiser@ethz.uucp --
>>...
>>    - no timestamping, no consistency checks when modifying definition modules...
>>    - identifiers imported in the definition module are not known in the
>>      implementation module, they must be imported again. This will generate a
>>      compile-time error in most other Modula-2 systems
>
>Though much that DEC does could make strong men queasy, the points
>mentioned above do not seem questionable.
>
>Simply stated, mod compiles .def files by means of the identity
>transformation, (saves time, you know :-) and the timestamp is
>available in the file's inode.  I suppose the .o file stores the
>last-mod-time for all DEFINITION MODULEs IMPORTed and compares them for
>consistency at link time.  Nothing more could be required.

This is not true, I tried the following example:

DEFINITION MODULE m1;
EXPORT a, b, c;
CONST a = 10;
TYPE b = (red, (* yellow, *) green, blue);
PROCEDURE c (VAR bb: b);
END m1.

IMPLEMENTATION MODULE m1;
PROCEDURE c (VAR bb: b);
BEGIN
   bb := blue;
END c;
END m1.

MODULE m2;
FROM m1 IMPORT a,b,c;
FROM io IMPORT Writef, output;
VAR aa: CARDINAL;
    bb: b;
BEGIN
   aa := a;
   bb := red;
   c (bb);
   IF    bb = red   THEN Writef (output, "red");
   ELSIF bb = green THEN Writef (output, "green");
   ELSIF bb = blue  THEN Writef (output, "blue");
   END;
END m2.

I compiled ("mod m1.mod m2.mod") and the result was, expectedly, "blue".
Then I edited the comments out of m1.def, thus changing the type "b" to contain
an additional literal. Re-linking the already compiled modules
("mod m1.o m2.o") worked without an error, running produced the same result,
"blue". Next I recompiled m2: "mod m1.o m2.mod". Again, no error was reported,
and running the program produced the result "green"!

Hence, THERE IS NO TIMESTAMPING, exactly as I said.

>As I read PIM2 ed3, identifiers IMPORTed into a DEFINITION MODULE
>cannot be visible in the matching IMPLEMENTATION MODULE unless
>IMPORTed.  While defs and imps come in pairs, they are distinct
>MODULEs.  Perhaps the rule causing confusion was the one that makes
>_objects_declared_ in the def available in the imp without IMPORT.

Imports ARE declarations! PIM2 ed2 p 143 (sorry, I don't have ed3 at hand, but
there should be no difference concerning this point):
"Every identifier occuring in a program must be introduced by a declaration,
unless it is a standard identifier."
This means, importing an identifier into a definition module declares this
identifier, and hence makes it "available in the corresponding implementation
module without explicit import." (PIM ed2 p 164)

The DEC compiler may be a good compiler after all, unfortunately it compiles a
language that is not Modula-2.

-- 
Gernot Heiser                      Phone:                +41 1/256 23 48
Institute for Integrated Systems   EAN/CSNET/ARPA:       heiser@ifi.ethz.chunet
ETH Zuerich                        EARN/BITNET/NETNORTH: GRIDFILE@CZHETH5A
CH-8051 Zuerich, Switzerland       EUNET/UUCP:   {seismo,...}!mcvax!ethz!heiser