Re: what if "languages" don't respond to 754R ?

[Jason Riedy <ejr@xxxxxxxxxxxxxxx>]

And David Hough writes:
> One argument in favor of languages standards committees acting
> later rather than sooner on new ideas is to see if any existing
> practice develops and what the costs and benefits are.

After the C++ debacles, the feeling I've received from some
mainstream language folks is that they want to return to this
traditional approach.  When the committee went out on a limb or
included something unfinished, they almost always were wrong
(e.g. export, valarray).

And non-mainstream languages don't have much existing code to
cause problems.  (Many also are much easier to parse and rewrite
automatically or have language extension mechanisms.)

There are a few unresolved issues including interactions with
dynamic typing (now mainstream with JavaScript and crew, you have
to deal, sorry) and how to interact with other expression
evaluation mechanisms.  Also how to express the requirements
appropriate to the language audience.

I'm half worried that languages *will* respond, and that the
response will cut off all other options with the excuse of "we
don't understand it, or how to do it properly, but the IEEE754r
document says we gotta make this way work."

The current B&C conflate issues and will be misunderstood and
misimplemented.  They should go or remain optional.

It would take too long to fully specify the evaluation mechanisms
in a way that *language* implementers and users understand.  At a
bare minimum, you need to rephrase everything in terms of
program-level types and not storage formats.  Then you'll see
this sticks out as being very unlike the rest of the standard
and in need of much more terminology and work to integrate...

Now I'll go back to being quiet and not delay things further.

Jason