Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwvax!dogie.macc.wisc.edu!csd4.milw.wisc.edu!cs.utexas.edu!uunet!mcvax!unido!iraun1!iravcl!uebau08 From: uebau08@iravcl.ira.uka.de Newsgroups: comp.lang.modula2 Subject: Re: Re^2: Error in PD Modula-2 compiler? Or just in my brain? Message-ID: <309@iravcl.ira.uka.de> Date: 19 Jun 89 16:43:21 GMT References: <340@actisb.UUCP> <1090@gmdzi.UUCP> <1231@infbs.UUCP> <1130@eiger.iis.UUCP> Lines: 31 Organisation: Universitaet Karlsruhe, IRA, F.R. Germany 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