Thread View: comp.lang.modula2
2 messages
2 total messages
Started by Vincent Broman
Fri, 15 May 1987 15:36
disgust at DEC
Author: Vincent Broman
Date: Fri, 15 May 1987 15:36
Date: Fri, 15 May 1987 15:36
36 lines
2645 bytes
2645 bytes
Said heiser@ethz.uucp -- > I had a look at the DEC [Powell] compiler when we got it and was disgusted.... > Probably the people who wrote it never programmed any Modula-2. > ... Much worse: definition modules are not compiled (and there is no compiler > option to fix that). Hence: > - no timestamping, no consistency checks when modifying definition modules. > Any real Modula-2 programmer estimates that as one of the most powerful > language features when developing large systems. > - 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. The _only_ reason one "compiles" DEFINITION MODULEs into binary form is to avoid lexing/parsing/checking them _every_time_ they are IMPORTed. 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. As a practical matter, though, it is hard to imagine a useful instance where one IMPORTs an identifier into a DEFINITION MODULE which is not then needed in the matching IMPLEMENTATION MODULE. Let's not puff on the subject of who is a "real Modula-2 programmer", hey? Vincent Broman, code 632, Naval Ocean Systems Center, San Diego, CA 92152, USA Phone: +1 619 225 2365 Internet: broman@nosc.mil Uucp: sdcsvax!nosc!broman
Re: disgust at DEC
Author: Gernot Heiser
Date: Sun, 17 May 1987 13:01
Date: Sun, 17 May 1987 13:01
80 lines
3863 bytes
3863 bytes
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
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads