Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!amdahl!uunet!pdn!alan From: alan@pdn.UUCP (Alan Lovejoy) Newsgroups: comp.lang.modula2 Subject: Re: more about ORD and VAL Message-ID: <3638@pdn.UUCP> Date: 3 Jul 88 17:43:42 GMT References: <8806300811.AA00246@klaus.olsen.uucp> Reply-To: alan@pdn.UUCP (0000-Alan Lovejoy) Organization: Paradyne Corporation, Largo, Florida Lines: 48 In article <8806300811.AA00246@klaus.olsen.uucp> Info-Modula2 Distribution Listwrites: >Pardon me, but what does the term "meaning-preserving coercion" denote? >As far as I understand type coercions in other languages, I believe the >current semantics are "meaning-preserving", that is, they preserve the >meaning of the memory and that is all. You cannot get rid of ORD, because >it returns the "ordinal" value in terms of a type CARDINAL. The type >conversion CARDINAL merely subverts the type checking mechanism. I know I am sorry if the terminology I used confused you (or anyone). And it did confuse you. The term coercion was used imprecisely. In the current language, CARDINAL(-1) would have the value 65535 on most systems. This is a "bit-preserving type coercion" in the terminology I usually use. What the BSI committee proposed (a previous posting indicates they now have a new proposal), was that CARDINAL(3.0) become a "meaning-preserving type conversion", which in the case of the example would have the value 3. The new proposal is that the syntax for this type of conversion be CONVERT(CARDINAL, 3.0). They want to avoid using VAL for this since may compilers use it as a synonym for the bit-preserving type transfers (even though Wirth's books define it as a meaning-preserving conversion). Perhaps they could use VALUE, instead of CONVERT or VAL. Although I liked the original proposal better (just using the type name). The proposed (and ISO accepted) syntax for bit-preserving transfers is CAST(CARDINAL, -1). CAST must be imported from SYSTEM. Although bit-preserving type transfers are necessary for systems programming, it is unfortunate that in the current language they are so easily accomplished while the far safer and even more important meaning preserving conversions are only haphazardly supported. For example, there is no standard way to convert between long and short types, INTEGERs and CARDINALs, or REALS to INTEGERS (TRUNC returns type CARDINAL, for some strange reason). Even worse, the syntax for each such conversion that is supported is different for each case! This makes it impossible to write portable code that converts one type into an equivalent value of another type when the types involved may change from system to system, because the types being converted are improperly and unnecessarily bound to the syntax of the conversion operator. This should be fixed. -- Alan Lovejoy; alan@pdn; 813-530-8241; Paradyne Corporation: Largo, Florida. Disclaimer: Do not confuse my views with the official views of Paradyne Corporation (regardless of how confusing those views may be). Motto: Never put off to run-time what you can do at compile-time!