[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: what if "languages" don't respond to 754R ?
On Fri, 13 Jul 2007 05:33:27 +0900, David Hough 754R work
<754r@xxxxxxxxxxx> wrote:
One assertion that comes up from time to time: language X will never make
the choices or codify the requirements that 754R says "languages shall."
Maybe this comes back to clear use of language again.
In the ISO arena, "shall" is reserved for requirements. You cannot water
it down by saying somewhere else that "well actually it doesn't have to".
That's a contradiction. By definition, a contradiction in the standard
is an error in the standard.
I don't know whether IEEE has codified this or not, but IMO even if it is
not codified it is very poor style to say "shall" when you don't mean that.
ISO codifies "should" for recommendations (one doesn't have to use
"should",
but if one does, that is what it means, i.e. the meaning is identical to
"it is recommended that"). (And, qua a previous message, "should" is not
an informal term!)
754R indicates that "languages shall" can be accomplished
in several ways (the following is from the 2006-10-04 draft which is
readily available, though it hasn't changed much since):
Wow. That seems a lot of verbiage just to water down "shall" to "should".
It's no wonder many non-committee-member commenters misunderstand your
intent! Would it not be simpler to state the recommendations as
recommendations
in the first place?
The preferred way, maxmimizing portability benefits
of code, is by action of language standards committees.
What is certain is that some if not most language standards committees
will tend to act later rather than sooner.
Right. The clearer and simpler 754R is the sooner action will occur.
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.
That's only if 754R isn't clear or simple enough to understand...
One argument in favor of language standards committees acting sooner
rather than later is that two or more incompatible existing
practices
might develop, and it might become impossible to standardize one
without standardizing all, which is effectively no standard at all.
That's not what usually happens with standards, cf C, C++, Fortran, Pascal,
all of whose standards neither (at various points) included conflicting
extensions nor omitted standardising extensions with potential conflicts.
In particular, the way C99 standardised 754 support was different from most
(all?) extensions, and conflicted with several (incompatible functions
with the same name).
Similarly, with Fortran 754 support was added by the 1998 Technical Report
(incorporated into F2003) and did not follow any existing practice.
Another thing that is certain is that none of this will happen so quickly
that onlookers will get dizzy.
In my view that is quite disappointing. I was one of many who wished the
next revision of Fortran to include support for 754R, and it is a great
disappointment to have watched 754R become overly complicated and late.
Is there still a simple standard inside 754R struggling to get out?