NCEG restrictions per Rex Jaeschke

[David G. Hough on validgh]

Date: Thu, 29 Nov 90 22:20:26 EST
From: uunet!aussie.COM!rex (Rex Jaeschke)
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.

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.)


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

----------------------------------------------------------------------------
Rex Jaeschke     |  Journal of C Language Translation  | C Users Journal
(703) 860-0091   |        2051 Swans Neck Way          | DEC PROFESSIONAL
rexaaussie.COM   |     Reston, Virginia 22091, USA     | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------