neitzel@infbs.UUCP (Martin Neitzel) (06/02/89)
Legend: MN> Martin Neitzel <neitzel@infbs> FvO> fransvo@maestro.htsa.aha.nl (Frans van Otten) PIM3> N. Wirth, "Programming in Modula2", 3rd corrected edition I wrote ealier: MN> 4. It is a known ambiguity in the Modula2 report: Can standard MN> identifiers be redefined or not? In procedures, definitely MN> yes, but the situation in modules is not clear at all. FvO> The situation is perfectly clear. We agree in the case of procedures (where redefinitions are possible), but have different opinions with respect to modules. FvO> [Correctly explains the case for procedures, and gives a nice FvO> overview about matters with respect to the tutorial and FvO> reference part of PIM3.] Warning: The following is nitpicking. I know. (However, when one has to implement a language, one has has to be nitpicking.) FvO> chapter 4, "Declarations and scope rules", first alinea: With my interpretation (allowing redefinitions): PIM3> " Every identifier occuring in a program must be introduced by a PIM3> declaration, unless it is a standard identifier. The latter are PIM3> considered to be predeclared, ... namely in the "standard environment" PIM3> ... and they are all valid in all parts of a program. ... Either you have provided your own declaration for the identifier, or the declaration of the standard environment can be found. PIM3> ... For this reason they are called pervasive. " They can be found across module borders without explicit import, that's certainly a "pervasive" property. FvO> This says it all. Valid in ALL parts of the program, FvO> pervasive... They always prevail, even when redeclared. This says it all. Valid in ALL parts of the program,... A (pervasive) declaration can always be found, even when not provided by the programmer. Now, is my mind totally out to lunch? I'm not saying that Frans or I are plain wrong, but the way I see it, the situation is not clear. FvO> So I decided for the compiler I'm developing: FvO> " The standard identifiers can be considered to be declared FvO> in every (local and global) module, prior to any import. FvO> Between the standard identifiers and the rest of the FvO> module (including the import part) is an imaginary FvO> procedure border. Importing may be considered the same as FvO> declaring. " This is a clear definition. (For you and me as implementors, there still is the possibility that standard id's can be redeclared in procedures and records, so we still have to be careful when we see one.) Life would be somewhat easier, if there was a clear cut between standard id's and the rest (e.g., the keyword solution), especially with respect to constant expressions. PIM4 just changed them back to the PIM2 version... gack! I also would appreciate it, if it were made clear that IM- and EXPORTed identifiers have to be viewed as declared. Now THAT would settle it (and match with Frans' interpretation and rule). Perhaps in PIM5? :-( Martin
federico@actisb.UUCP (Federico Heinz) (06/04/89)
heiser@iis.UUCP (Gernot Heiser) writes: >So he ended >up doing away with type transfer functions, assigning their former meaning to >VAL and putting the latter into SYSTEM. That's the way it is implemented in all >the (one pass) compilers that left ETH in the last few years. Well, I think this pretty settles my original question of whether the compiler was "broken" or not, and the answer is NO. The PD compiler I'm talking about is a port of a one-pass compiler from ETH, so type transfer has to be done with VAL. Now... when will we ever know which type transfer is accepted as a standard? And does Wirth say anything on this topic in PIM4? It would be pretty inconsistent if the compilers from his own house wouldn't comply with the book. -- Federico Heinz "I can resist anything but temptation" -- Oscar Wilde From Europe: ...!mcvax!unido!tub!actisb!federico From elsewhere: ...!uunet!pyramid!/
kloppen@gmdzi.UUCP (Jelske Kloppenburg) (06/06/89)
And I am waiting for apologies from Martin Neitzel.
Kloppenburg@kmx.gmd.dbp.de
UUCP: kloppen@gmdzi
In real life: Jelske Kloppenburgneitzel@infbs.UUCP (Martin Neitzel) (06/09/89)
In article <345@actisb.UUCP> federico@actisb.UUCP (Federico Heinz) writes:
FH>
FH> And does Wirth say anything on this topic in PIM4?
PIM4 is exactly like PIM3 with respect to type transfer functions
and VAL().
While we are at PIM3/4 comparisons: I have hacked the PIM3 reference
part into the computer. (When I was writing my M2-interpreter, I had
to grep every hour after this or that...)
Is anybody willing to do the same for PIM4? We could try to run a
sort of diff against them and post the result. Unlike the 3rd
edition, PIM4 has no change marks.
Or even better: Could anybody at ETH provide us with the diffs?
Martin