Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!cs.utexas.edu!uunet!mcvax!cernvax!ethz!iis!heiser From: heiser@iis.UUCP (Gernot Heiser) Newsgroups: comp.lang.modula2 Subject: Re: Re^2: Error in PD Modula-2 compiler? Or just in my brain? Message-ID: <1130@eiger.iis.UUCP> Date: 1 Jun 89 19:04:20 GMT References: <340@actisb.UUCP> <1090@gmdzi.UUCP> <1231@infbs.UUCP> Reply-To: heiser@iis.ethz.ch (Gernot Heiser) Organization: ETH Zuerich, Switzerland Lines: 30 Summary: Expires: 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