phipps@garth.UUCP (Clay Phipps) (01/31/89)
In article <186@m2xenix.UUCP> randy@m2xenix.UUCP (Randy Bush) writes: >... The professor heard the pleas. Modula-2 has unchecked casts. I would prefer the current (existing) form (as I understand it), because it seems to require the least special-case compiling. > pointer := PointerTypeName ( ArbitraryValueOfSameNumberOfBits ) ^^^^^^^^^^^^^^^ In the first example, any apparent function reference whose function-id is the name of a type must be treated as a cast; however, the expression within the parentheses can be evaluated just as it would be as the actual-parameter for a function invocation. >Or the new form being suggested in recent ISO work > > pointer := SYSTEM.CAST ( PointerTypeName, ArbitraryValueOfSameNumberOfBits ) ^^^^^^ ^^^^ ^^^^^^^^^^^^^^^ In the second example, any apparent function reference with the special name "SYSTEM.CAST" (or more likely, first "SYSTEM", then "CAST") must be treated as a special case. Furthermore, the first actual parameter must be treated as a special-case, because it is the name of the target type, not an expression to be evaluated. Only the last actual parameter can be evaluated normally. I think of the first example as requiring only 1 special-case decision (trivially handled with semantic actions during parsing), and the second example as requiring 2 of them (still straightforward to handle with semantic actionsa, but not as simple). What does the decreased simplicity of handling the second example buy ISO ? Is the ISO proposal trying to make way for a distinction between casts and conversions (the latter changing the bit patterns, e.g., from that for floating 0.1e2 to string '10.0' or integer 10) ? -- [The foregoing may or may not represent the position, if any, of my employer] Clay Phipps {ingr,pyramid,sri-unix!hplabs}!garth!phipps Intergraph APD, 2400#4 Geng Road, Palo Alto, CA 93403 415/494-8800
randy@m2xenix.UUCP (Randy Bush) (02/07/89)
In article <2493@garth.UUCP> phipps@garth.UUCP (Clay Phipps) writes: >In article <186@m2xenix.UUCP> randy@m2xenix.UUCP (Randy Bush) writes: >> pointer := PointerTypeName ( ArbitraryValueOfSameNumberOfBits ) > ^^^^^^^^^^^^^^^ >> pointer := SYSTEM.CAST ( PointerTypeName, ArbitraryValueOfSameNumberOfBits ) > ^^^^^^ ^^^^ ^^^^^^^^^^^^^^^ >I think of the first example as requiring only 1 special-case decision >(trivially handled with semantic actions during parsing), >and the second example as requiring 2 of them >(still straightforward to handle with semantic actions, but not as simple). I agree. The second case is more complex to analyse. >What does the decreased simplicity of handling the second example buy ISO ? >Is the ISO proposal trying to make way for a distinction between casts and >conversions? Well, casts and conversions were always clearly distinct in the language, though some claim that users were easily confused. TypeName ( object ) (* cast *) VAL ( TypeName, value ) (* conversion *) But the committees noticed two things o The safe conversion was harder to write than the cast o The cast, which was dirty, did not require an import from SYSTEM The BSI then suggested TypeName ( value ) (* conversion *) SYSTEM.CAST ( TypeName, object ) (* cast *) but other ISO folk felt that redefining the semantics of T(x) would break existing code. (There was also much flamage about changing VAL to CONVERT, removing the 'redundant' VAL, ORD, CHR, TRUNC, etc., the story of which only true language standards committee masochists deserve.) So, a compromise was reached (don't you just _love_ committees:-). TypeName ( object ) (* cast, still supported, but deprecated *) SYSTEM.CAST ( TypeName, object ) (* cast, new approved explicit form *) VAL ( TypeName, value ) (* conversion *) This leaves old code still working, makes new code more explicit about use of inherently unsafe casting, and, most important, the committee could get on to the trivial parts of the language such as import/export rules. Actually, aside from resenting the inordinate amount of time spent on a trivial issue, the current proposal seems reasonable to me. And you? Anyone saying 'no' is hereby sentenced to a full day of discussing this in an uncomfortable room in a strange town with twenty other language lawyers. -- { mcvax!uunet!oresoft, tektronix!percival!qiclab } !m2xenix!randy Randy Bush
holt@turing.toronto.edu (Ric Holt) (02/07/89)
The use of "conversions" and "casts" in Turing follow a similar philosophy
to that in Modula 2, but with different terminology and syntax. Perhaps
the way this is done may be of interest to the ongoing discussion of
Modula 2's methods.
In Turing there are "type transfer functions", for example, strint("11")
transfers (converts) the string "11" to the int (integer) 11. There is
a complete set of these functions (for predefined types) built in to
the language, eg, intstr, realstr, etc. These are, incidently, used as
the basis for defining input/output statements, which implicitly convert
internal values to strings and vice versa. These are mathematically
defined, ie, are machine independent.
In Turing Plus (but not in the clean subset, Turing proper), there
are also "type cheats", which you may want to call "casts".
These take one value and consider its representation to be a value of
another type; for example, type (char, i) takes value i (perhaps a one
byte integer) and considers it to be a character, without any generation
of code or change of the bits (no change of representation). These
"type cheats" are inherently dirty (implementation dependent); that's
why Turing proper (a mathematically defined language) avoids them,
but Turing Plus (which supports systems programming) includes them.
Turing Plus includes a "short form" # for one of the common uses of type
cheats, which is the case in which you want to "neutralize" or "naturalize"
a value so as to interpret as an unsigned number. For example, # c,
where c is a char variable, considers the value to be an unsigned number.
This is equivalent to the longer form: type ( nat1, c ) in other words
# c is short for type cheating c to a one byte natural (unsigned) number.phipps@garth.UUCP (Clay Phipps) (02/08/89)
In article <196@m2xenix.UUCP> randy@m2xenix.UUCP (Randy Bush) writes: >In article <2493@garth.UUCP> phipps@garth.UUCP (Clay Phipps) writes: >>... Is the ISO proposal trying to make way for a distinction between >>casts and conversions [in Modula-2] ? >Well, casts and conversions were always clearly distinct in the language,... > TypeName ( object ) (* cast *) > VAL ( TypeName, value ) (* conversion *) I confess that I had forgotten about "VAL" in the long time since I've looked at Modula-2. According to the "Report On The Programming Language Modula-2" (in Wirth: _Programming In Modula-2_, 1st ed., 1982), the "VAL" standard procedure is applicable only to values of ordinal types, excluding reals and strings, and, thereby, falling short of what I expected. Perhaps the applicability of "VAL" was broadened in the 2nd edition, which appeared a month or so after I bought my copy of the 1st edition. The apparent absence of standard procedures to convert between string and scalar types (and vice versa) without performing I/O is particularly surprising in a language deriving its name from "modules". Have string conversion standard procedures been added ? >So, a compromise was reached (don't you just _love_ committees:-). >... aside from resenting the inordinate amount of time spent on a >trivial issue, the current proposal seems reasonable to me. And you? Just to be on the safe side -- nein ! nyet ! :-}. What the heck, you're stuck with the earlier decisions. >Anyone saying 'no' is hereby sentenced to a full day of discussing this in >an uncomfortable room in a strange town with twenty other language lawyers. I've already know what that is like, although not for that committee, and only if San Jose qualifies as a "strange town". I'd prefer that to the >=2 days that I've wasted trying to install a hard disk on my PC, sans even the most rudimentary documentation on controller and drive. Wanna trade hassles ? Now bring on those import/export rules ... 8-| -- [The foregoing may or may not represent the position, if any, of my employer] Clay Phipps {ingr,pyramid,sri-unix!hplabs}!garth!phipps Intergraph APD, 2400#4 Geng Road, Palo Alto, CA 93403 415/494-8800
randy@m2xenix.UUCP (Randy Bush) (02/14/89)
In article <2526@garth.UUCP> phipps@garth.UUCP (Clay Phipps) writes: >According to the "Report On The Programming Language Modula-2" >(in Wirth: _Programming In Modula-2_, 1st ed., 1982), >the "VAL" standard procedure is applicable only to values of ordinal types, >excluding reals and strings, and, thereby, falling short of what I expected. In the current (internal) draft of the standard, VAL will convert to and from REAL and LONGREAL. >Have string conversion standard procedures been added ? Current draft proposals do not add to the language (i.e. standard procedures) to convert string literals or arrays of char to or from numerics, but do specify library procedures to these ends. >What the heck, you're stuck with the earlier decisions. We are trying to take seriously the mandate to standardize existing practice. There exists a fair body of code out there. I know of applications over 2*10^6 lines of code. Modulans are quiet but prolific. And, BTW, yes I do consider San Jose a strange town. :-) -- { mcvax!uunet!oresoft, tektronix!percival!qiclab } !m2xenix!randy Randy Bush