NCEG restrictions && X3J11's views on extensions

[validgh!uunet!att!attunix!dfpaSun.COM]

(Sorry about the delayed reply; I haven't had time to spare recently.)

Rex Jaeschke writes:
>Subject: Proposed IEEE operators etc.
>
>I've just returned from an ISO C meeting in Copenhagen. For several 
>years now Denmark has been proposing alternate (more readable) versions 
>for some trigraphs. For example, digraphs such as (: and :) for { and 
>}. They have also been proposing new keywords. Clearly, this stuff is 
>very special purpose and is very hard to sell to those (most everyone 
>else in the C world) not affected by these defficiencies/extensions. 
>X3J11 has soundly voted against ALL such proposals and to force the 
>issue (I'm the US rep to ISO C) I stated at the ISO C meeting that I
>could see no way that further proposals along this vein would be
>acceptable to X3J11.  (In separate communications I find the Japanese
>expressing similar opposition.)
>
>The upshot is that once I brought this to a head we then identified 
>just what additions to C would likely be universally acceptable to 
>various national bodies. It pretty much came down to:
>
>	Preferably NO new keywords or other tokens although
>	alternate spellings for existing tokens would be OK.
>
>Of course, macros that hide functions or hidden keywords would be OK.

I do not completely agree with Rex's statement.  The "no new keywords"
is, I believe, a good goal.  As Rex has pointed out, the hidden keyword
approach gives the flavor of new keywords without causing programs to
break.

It is the other part of his statement that I believe to be reversed.
Alternative spellings for existing tokens is, in my opinion, much more
difficult to get accepted than new tokens for new concepts.  For example,
I believe the NCEG-proposed comparison operators (that completely cover
the unordered cases) would be acceptable to X3J11 if a strong enough
case were made for their need.  On the other hand, different spellings
of existing tokens is often seen as a gratuitous violation of the
principle "provide only one way to do an operation".  [Rationale, p3.]
In particular, since the "!" approach to the new operators has more
utility than the "?" scheme--they provide the succinct expression of
comparisons that would otherwise be best written as "!(...)" and thus
apply to more than just unordered situations--, I would be surprised if
NCEG did not adopt the "!"-based operators and would then be more
surprised if the next ANSI C (C99?) were not to include the same.

>Also, polluting the existing headers is bad news. Specifically, the 
>Japanese were informed that their proposed multi-byte extensions would 
>have a MUCH better chance if they were all confined to a NEW header. 
>(previously they proposed adding to string.h, stdio.h, and others.)

I completely agree, just as with new keywords, new (not already reserved)
entries in existing standard headers should be avoided whenever there is
a reasonable alternative.

>
>
>These issues have been bothering me for some time now and since I have 
>been one of those pushing to have the ground rules established AND I'm 
>the NCEG convenor, it's appropriate that I voice my concerns before we 
>(NCEG) get too far down a one-way path.  The impact this all has on
>NCEG then is, at the very least, that introducing the 8-9 new
>operators for ordered/unordered comparisons, etc., will very likely
>be a very hard sell to X3J11 as well as the rest of the world.  There
>is little point in us defining a strategy that while it makes sense
>within itself, no one else will adopt it.
>
>My strong suggestion therefore is to absolutely avoid new tokens if 
>possible and to not pollute existing headers. Except in extreme 
>circumstances I don't see that I can support proposals that violate 
>these restrictions. Certainly, my X3J11/ISO C role will require me to 
>consistanently support the trail I've started to blaze there.
>
>Rex

As I've stated above, I disagree with Rex's view on the X3J11 position
on new nonkeyword tokens.  Through appropriate spelling choices, new
tokens can never invalidate existing code and are often the easiest new
feature to add to an implementation--particularly if the tokens are
operators that match an existing slot in the grammar.  Although alternate
spellings for existing tokens is even easier to add to implementations,
I believe the perceived lack to utility will out-balance its gains.



On a related topic, others have stated that ANSI C++ is the appropriate
vehicle for what would otherwise have been straightforward extensions to
C.  The claim is that X3J11 is too "hardened" to accept reasonable
additions.  X3J11/NCEG seems to me to be willing to accept compatible
changes that have a strong enough justification; and I want to add my
voice to the "let the ANSI C++ committee do its job" camp.  They have
already taken on the not inconsiderable task of standardizing a language
that has "interesting" corners yet to be explored.  The first standard
for a language should be, in my opinion, a place to codify that which is
"existing practice" (even if such may not be well-liked) and should
include the minimum number of additions to cover the well-understood
deficiencies, if any.  The art of "standardize something new because
otherwise there will be incompatible implementations" is not something
to attempt lightly.  Again, in my opinion, there has been far too much
of this art in the last few years.  Keep X3J16's job "simple".  [KISS]

Dave Prosser