🚀 go-pugleaf

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