Path: utzoo!attcan!uunet!mcvax!cernvax!ethz!aplusl From: aplusl@ethz.UUCP (Albert Meier) Newsgroups: comp.lang.modula2 Subject: Type Conversion Summary: Type conversion proposal for ISO (South Africa, Switzerland) Message-ID: <491@ethz.UUCP> Date: 1 Jul 88 17:06:22 GMT Organization: ETH Zuerich Lines: 205 Expires: Sender: Reply-To: aplusl@bernina.UUCP (Albert Meier) Followup-To: Distribution: comp.lang.modula2 Organization: ETH Zuerich, Switzerland Keywords: Here is now the exact proposal from Pat Terry (SA) and me (CH). We have been asked to post it. As mentioned before for Switzerland it is the second choice (the third has been decided in Nice, the first choice is reconsidering the BSI proposal voted against in Nice). Pat has no access to Usenet but he kindly greets you all. Here it comes: To: Persons interested in type conversions in Modula-2 From: Pat Terry, Computer Science, Rhodes University, GRAHAMSTOWN 6140 _______________________________________________________________________________________________________________ The Nice ISO standardisation meeting adopted a proposal of mine concerning "safe" type conversions, I suspect reluctantly, and with good reason. The proposal was motivated mainly by a desire to clear a log-jam, and with an eye on what was about to follow (the discussion on the status of ORD, TRUNC and FLOAT). Albert Meier and I would like to make a compromise suggestion. It is of interest to review the various proposals made for safe conversions. The position in PIM, I believe, can be summarised in the following table, which omits the potential complications from range errors. To convert an Expression of type Integer Cardinal Real Longreal Char Enum To a result of type Integer - VAL * * * * Cardinal VAL/ORD - TRUNC * ORD ORD Real * FLOAT - * * * Longreal * * * - * * Char * VAL/CHR * * - * Enum * VAL * * * - Here the * entries represent "no direct one-step conversion" and the - entries represent "no conversion needed". "Enum" means any enumerated type, including BOOLEAN. In fact, I am not certain how one converts directly from an integer to a cardinal. A close reading of PIM suggests that ORD is used, but I have seen VAL advocated, and I have seen compilers do strange things here too. Another viewpoint is that ORD(MIN(INTEGER)) should return 0, but this is really rather ludicrous, and I do not think anyone would take this seriously. One is struck with the sparseness of the table. Some conversions are really horrible, for example from integer to real. Presumably one really needs code like IF I > 0 THEN R := FLOAT(ORD(I)) ELSE R := - FLOAT(ORD(ABS(I)) END which would be very tiresome if complicated compound expressions were needed. One gets the distinct impression that the implementors of the original compilers never have any need for writing any number-crunching programs - or indeed, any that use REAL at all. One could level the same criticism at their total disregard for COMPLEX, but that is a rather different issue. When I teach students here they are completely amazed at the difficulty which using REAL seems to present. The BSI proposal for safe conversions, as I can see it (stripped of the LONGCARD, LONGINT, SHORTINT etc baggage which I think we can agree is a side issue here), can be summarised in the following table. To convert an Expression of type Integer Cardinal Real Longreal Char Enum To a result of type Integer - INTEGER INTEGER INTEGER * * Cardinal CARDINAL - CARDINAL CARDINAL CARDINAL CARDINAL Real REAL REAL - REAL * * Longreal LONGREAL LONGREAL LONGREAL - * * Char * CHAR * * - * Enum * DAYS * * * - The proposal adopted at the Nice meeting can be summarised as follows To convert an Expression of type Integer Cardinal Real Longreal Char Enum To a result of type Integer - CONVERT CONVERT CONVERT * * Cardinal CONVERT - CONVERT/TRUNC CONVERT CONVERT/ORD CONVERT/ORD Real CONVERT CONVERT/FLOAT - CONVERT * * Longreal CONVERT CONVERT CONVERT - * * Char * CONVERT/CHR * * - * Enum * CONVERT * * * - The objection to this is aesthetic - it is very clumsy to use CONVERT(T,x) when a nice simple function would look better. The objections to the BSI proposal are really that they introduce new semantics into old syntax. The argument in favour of ORD, TRUNC and CHR is that they are familiar and already part of the language. The point need to be made that the "standard" functions in Modula-2 are mostly highly non-standard, in that many of them are in fact generic. Once this is accepted, there seems no reason why similar functions should not be as generic as ORD (which maps "any" ordinal type to CARDINAL), for example, and why FLOAT should not be able to map "any" numerical value to REAL. Admittedly, REAL would be a better name than FLOAT, but that's history that we cannot rewrite. The suggestion Albert and I would like to make is summarised in the following table. It introduces three new pervasive identifiers INT, CARD and LFLOAT. To convert an Expression of type Integer Cardinal Real Longreal Char Enum To a result of type Integer - INT INT INT INT INT Cardinal CARD/ORD - CARD/TRUNC CARD CARD/ORD CARD/ORD Real FLOAT FLOAT - FLOAT * * Longreal LFLOAT LFLOAT LFLOAT - * * Char CHR CHR * * - * Enum CONVERT CONVERT * * * - CHR, TRUNC and ORD are retained for historical reasons. The matrix is now symmetric, and the usage of CONVERT would probably be minimal in practice. CARD could be dispensed with, and ORD used throughout, but CARD and INT would make a nice pair, with the intent fairly obvious. There is a lurking problem in that if an implementation wants to have SYSTEM.LONGCARD or SYSTEM.SHORTINT or whatever, this seems to require a further plethora of names. However, we could still demand that CARD, INT, FLOAT, LFLOAT apply to arguments of any of these types, and would need only to introduce LCARD, LINT, SCARD, SINT and so on. SSS N N V V SNV SWISS STANDARDIZATION BODY S NN N V V 149/UK2 Programming Languages SSS N N N V V Chairman Albert Meier, CH-8906 Bonstetten S N NN V V . E-mail aplusl@ifi.ethz.(ch/UUCP) SSS N N V ...mcvax!cernvax!ethz!aplusl