Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!pdn!oz!alan
From: alan@oz.nm.paradyne.com (Alan Lovejoy)
Newsgroups: comp.lang.modula2
Subject: Re: Re^2: Error in PD Modula-2 compiler? Or just in my brain?
Message-ID: <6188@pdn.paradyne.com>
Date: 14 Jun 89 14:34:09 GMT
References: <340@actisb.UUCP> <1090@gmdzi.UUCP> <1231@infbs.UUCP> <1130@eiger.iis.UUCP>
Sender: news@pdn.paradyne.com
Reply-To: alan@oz.paradyne.com (Alan Lovejoy)
Organization: AT&T Paradyne, Largo, Florida
Lines: 55

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.