neitzel@infbs.UUCP (Martin Neitzel) (05/29/89)
There are some "hard facts" regarding the original questions at the end
of this article. Stay tuned. But before that, I just _have_ to insert
a small reminder for all contributors of this group.
In article <123@foo> Joe KouldBeAnybody writes:
JK>
JK> I compiled these files whith the XYZ-Modula2 and no errors were
JK> or were not reported. There may be another cause for your error.
Listen To What The Man Said:
N. Wirth in "Programming in Modula2", 3rd corrected edition, and 4th ed.,
"1. Introduction":
pim3>
pim3> This report is not intended as a programmer's tutorial.
pim3> It is intentionally kept concise, and (we hope) clear.
pim3> Its function is to serve as a reference for programmers,
pim3> implementors, and manual writers, and as an arbiter, should
pim3> they find disagreement.
Though the report fails to meet these goals in several ways, it can be
used as primary reference, and should be. Thank you for your attention.
Back to the original question:
Q: PD-compiler or brain broken?
A: Brain ok. ("Stay fit and healthy until you're dead." [D. Barry])
1. What about the assignment "newStack := newList"?
A declaration "TYPE Stack = List" introduces a new identifier for the
same type [pim3, 6.1]. No type conversion of any kind is ever needed
in contexts involving "both" types. They are "compatible" [pim3, 6.3].
From this follows that even "CreateList (newStack)" would be a valid
procedure call.
2. What about the "bug-fix" involving type transfers?
PIM3, "12. System-dependent facilities" (unchanged in pim4)
pim3>
pim3> Besides those exported from the pseudo-module SYSTEM, there are
pim3> two other facilities whose characteristics are system-dependent.
pim3> The first is the possibility to use a type identifier T as a
pim3> name denoting the ``type transfer function'' from the type of
pim3> the operand to the type T. Evidently, such functions are data
pim3> representation dependent, and they involve no explicit
pim3> conversion insrtuctions. [...]
Thus, the cast "Stack (newList)" must be accepted by any conforming
compiler. Notwithstanding the fact that your program may core dump at
runtime at the very next occasion. So, there may very well exist a
conforming Modula2-System, where the type transfers won't be useful
for even the most simplest things.
Martin Neitzelfederico@actisb.UUCP (Federico Heinz) (05/29/89)
I haven't tried out your version of the sources, but I can pinpoint a
difference between our approaches: you import List as a type in the
DEFINITION module for Stacks, while I do it only in the IMPLEMENTATION.
You also declare Stack to be equal List in the DEFINITION, while I want
to keep it opaque. Maybe I shouldn't be so nit-picking, but I thought
this kind of information-hiding was what Maodula-2 programming was all
about. Thanks for the information on type-transfer functions, though
(as usual, quite, but not totally unlike the standard. I love it).
--
Federico Heinz "I can resist anything but temptation"
-- Oscar Wilde
From Europe: ...!mcvax!unido!tub!actisb!federico
From elsewhere: ...!uunet!pyramid!/neitzel@infbs.UUCP (Martin Neitzel) (05/29/89)
kloppen@gmdzi.UUCP (Jelske Kloppenburg) writes:
JK>
JK> The type transfer in the TU Muenchen Modula2 is as follows:
JK> FROM SYSTEM IMPORT VAL; [...]
JK> BEGIN ... c:=VAL(CARDINAL,b); ....
JK>
JK> I learned it from reading some source in the package.
From reading Wirth's Modula2 report, [10.2 "Standard procedures"], you
might learn even more.
1. VAL is _not_ a "type transfer function" [pim3, 12.], but a standard
procedure [pim3, 10.2]. Especially, VAL conversions guarantee to
preserve the value, which may involve changes in the representation.
Type transfers, on the other hand, do not.
2. Usage of VAL doesn't require SYSTEM. (pim3: "Standard procedures are
predefined.")
3. This VAL is constrained to some integral types and won't help in the
original "TYPE Stack = List" problem.
4. It is a known ambiguity in the Modula2 report: Can standard
identifiers be redefined or not? In procedures, definitely yes, but
the situation in modules is not clear at all. Depending on this
ambiguity, the TU Muenchen compiler may or may not be considered
PIM3-conforming ("broken" is too harsh a word in this context).
In any case, the compiler has to provide a standard procedure VAL in
addition to the SYSTEM-VAL mentioned by you.
Martin Neitzelfransvo@maestro.htsa.aha.nl (Frans van Otten) (05/29/89)
Martin Neitzel writes: >4. It is a known ambiguity in the Modula2 report: Can standard > identifiers be redefined or not? In procedures, definitely yes, but > the situation in modules is not clear at all. The situation is perfectly clear. But first, read this: I realize the 'report'-part of the book should contain all on Modula-2. But let me quote Wirth from some other chapters in Programming in Modula-2, third, corrected edition: In chapter 11, "The concept of locality", Wirth writes: " The standard identifiers of Modula are considered to be declared in an imaginary procedure enclosing the program. " " These rules may also be remembered by the algorithm is which the declaration of a given identifier i is searched: First, search the declarations of the procedure P in whose body i occurs; if the declaration of i is not among them, continue the search in the procedure surrounding P; then repeat this same rule until i is found. " So it is legal to redeclare a standard identifier within a procdure. Nothing is stated yet about redeclaring them in a module. From this quatation you could also conclude that standard identifiers are unknown in local modules (unless specifically imported), but the module-concept is introduced after that, in chapter 23. In chapter 24, "Definition and implementation parts", we find: " Standard identifiers are automatically imported into all modules. " Which settles that problem. Now in chapter 26, "Local modules", we read: " ... (unless one also considers a main program to be not only a module, but also a procedure). " A bit ambiguous, but you can read in this that Wirth doesn't think this viewpoint is wrong. And if a main program also is a procedure, you can redeclare identifiers. Remember, Wirth wrote (I quote again): " The standard identifiers of Modula are considered to be declared in an imaginary procedure ENCLOSING the program. " (Emphasis mine.) Although this doesn't say anything about local modules, it would be unlogical to allow redeclaration in the main module but not in local modules. The above is from the "normal" chapters in the book, not from the report. The report should contain all information on Modula-2, and serve as a reference and arbiter. So forget the above, and read on: In the report we find in chapter 4, "Declarations and scope rules", first alinea: " Every identifier occuring in a program must be introduced by a declaration, unless it is a standard identifier. The latter are considered to be predeclared, and they are all valid in all parts of a program. For this reason they are called pervasive. " This says it all. Valid in ALL parts of the program, pervasive... They always prevail, even when redeclared. So the situation is perfectly clear (from the report). Of course, compared to the other quotations, this is not consistent. So I decided for the compiler I'm developing: " The standard identifiers can be considered to be declared in every (local and global) module, prior to any import. Between the standard identifiers and the rest of the module (including the import part) is an imaginary procedure border. Importing may be considered the same as declaring. " -- Frans van Otten | fransvo@maestro.htsa.aha.nl or Algemene Hogeschool Amsterdam | fransvo@htsa.uucp or Technische en Maritieme Faculteit | [[...!]backbone!]htsa!fransvo
heiser@iis.UUCP (Gernot Heiser) (06/02/89)
In article <1231@infbs.UUCP> neitzel@infbs.UUCP (Martin Neitzel) writes: >kloppen@gmdzi.UUCP (Jelske Kloppenburg) writes: >1. VAL is _not_ a "type transfer function" [pim3, 12.], but a standard > procedure [pim3, 10.2]. Especially, VAL conversions guarantee to > preserve the value, which may involve changes in the representation. > Type transfers, on the other hand, do not. > >2. Usage of VAL doesn't require SYSTEM. (pim3: "Standard procedures are > predefined.") Correct according to THE BOOK. However, N.W. sometimes changes his mind too. In particular about three years ago he decided that use of the ("unsafe") type transfer functions should be discouraged. Furthermore being a system dependent thing, type coercions should really be designated as such by having to be imported from SYSTEM. In addition he apparently also decided that the ("safe") type casts as originally provided by the standard function VAL were unnecessary. 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. Last I heard from the standardisation commitee is that they were undecided which of the two "standards" to follow (or even come up with a third alternative). -- Gernot Heiser Phone: +41 1/256 23 48 Integrated Systems Laboratory CSNET/ARPA: heiser%iis.ethz.ch@relay.cs.net ETH Zuerich UUCP (new): heiser@iis.uucp CH-8092 Zuerich, Switzerland UUCP (old): {uunet,mcvax,...}!iis!heiser
alan@oz.nm.paradyne.com (Alan Lovejoy) (06/14/89)
In article <1130@eiger.iis.UUCP> heiser@iis.ethz.ch (Gernot Heiser) writes: <In article >1231@infbs.UUCP> neitzel@infbs.UUCP (Martin Neitzel) writes: <>kloppen@gmdzi.UUCP (Jelske Kloppenburg) writes: <>1. VAL is _not_ a "type transfer function" [pim3, 12.], but a standard <> procedure [pim3, 10.2]. Especially, VAL conversions guarantee to <> preserve the value, which may involve changes in the representation. <> Type transfers, on the other hand, do not. <> <>2. Usage of VAL doesn't require SYSTEM. (pim3: "Standard procedures are <> predefined.") < <Correct according to THE BOOK. However, N.W. sometimes changes his mind too. In <particular about three years ago he decided that use of the ("unsafe") type <transfer functions should be discouraged. Furthermore being a system dependent <thing, type coercions should really be designated as such by having to be <imported from SYSTEM. But, EVERYTHING is "system-dependent"!!! After all, the machine code for "INC(i)" varies according to the CPU type. So we should import INC from SYSTEM, then? I don't think so. What should be imported from SYSTEM are things whose source-level SYNTAX, SEMANTICS or USAGE-PROTOCOL may vary among different implementations in such a way that the correctness of code which uses those things depends upon the differences. It should NEVER be necessary to change the SYNTAX, SEMANTICS or USAGE-PROTOCOL of a function which provides meaning-preserving conversions between ordinal types. So there is no justification for requiring VAL to be imported from SYSTEM. <In addition he apparently also decided that the ("safe") type casts as <originally provided by the standard function VAL were unnecessary. So he ended Does this mean he decided to do away with strong type checking and replace it with automagical safe type conversions in expressions (at least with regard to ordinal types)? If not, then "safe" type casts are absolutely essential! With "safe" (meaning-preserving) conversion one can write portable code. With only "unsafe" (bitpattern-preserving) conversion, one can NOT write portable code. <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. < <Last I heard from the standardisation commitee is that they were undecided <which of the two "standards" to follow (or even come up with a third <alternative). Only PUBLISHED standards are valid, enforceable or worthy of consideration. If not, then there are NO "standard" implementations because NO-ONE implements both "ARRAY OF ARRAY OF REAL" and functions whose return-types are not restricted to ordinals (both of which have been informally "approved" by Wirth in private written communications). Alan Lovejoy; alan@pdn; 813-530-2211; AT&T Paradyne: 8550 Ulmerton, Largo, FL. Disclaimer: I do not speak for AT&T Paradyne. They do not speak for me. ______________________________Down with Li Peng!________________________________ Motto: If nanomachines will be able to reconstruct you, YOU AREN'T DEAD YET.
uebau08@iravcl.ira.uka.de (06/19/89)
In article <1130@eiger.iis.UUCP>, heiser@iis.UUCP (Gernot Heiser) writes: > In article <1231@infbs.UUCP> neitzel@infbs.UUCP (Martin Neitzel) writes: >>kloppen@gmdzi.UUCP (Jelske Kloppenburg) writes: >> procedure [pim3, 10.2]. Especially, VAL conversions guarantee to >> preserve the value, which may involve changes in the representation. >> Type transfers, on the other hand, do not. >> > > Correct according to THE BOOK. However, N.W. sometimes changes his mind too. In > particular about three years ago he decided that use of the (UNSAFE) type > transfer functions should be discouraged. Furthermore being a system dependent > thing, type coercions should really be designated as such by having to be > imported from SYSTEM. > > In addition he apparently also decided that the (SAFE) type casts as > originally provided by the standard function VAL were unnecessary. 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. > > Last I heard from the standardisation commitee is that they were undecided > which of the two STANDARDS to follow (or even come up with a third > alternative). > -- > Gernot Heiser Phone: +41 1/256 23 48 > Integrated Systems Laboratory CSNET/ARPA: heiser%iis.ethz.ch@relay.cs.net > ETH Zuerich UUCP (new): heiser@iis.uucp > CH-8092 Zuerich, Switzerland UUCP (old): {uunet,mcvax,...}!iis!heiser