No subject

[Donn Terry]

Being one of the few (if any?) crossover participants in this group and
in internationalization (i18n) I have to comment!

The use of locales for changing the behavior of floating math as suggested
in Fred Tydeman's letter introduces just too much complexity.  Locales
are needed for internationalization issues, and right now represent
a 3-dimensional space (at least to those following the X/Open notation
for locales).  Adding several more dimensions, many of which
are meaningless to the average user, is a disservice to the user.

(The three dimensions are the country (for currency, etc.), the 
language (for collation, messages) and codeset.  (Country != language
in countries like Canada, Switzerland, and in practice even the US).)

I also feel that having detailed control of different sub-aspects of the
NCEG results is less-than desireable.

One of the (obvious) consequences of the namespace pollution rules that
X3J11 introduced was that it makes it VERY difficult to extend the language
without impacting existing applications.   I would suggest that a notation
where the program asserts which version of the language it expects would
allow upwards revision.  Rather than try to specify the details of
an implementation, I would suggest that a single symbol be reserved
where a conforming program shall define the value to be one of the 
values specified in the standard.  The value would state the level
of the language accepted.   This could be paired up with a requirement
that a specified header shall be included after this definition.  These
two together allow any reasonable range of implementations, without
having to specify the implementation.  Some sample wording, with the
names being chosen arbitrarily (and __STDC__ avoided because of the
problems already recognized with it).

	Each conforming application shall include the following
	declaration befoere any header specified by this standard
	is included:
		#define _STD_C_REVISION 1992

	Additionally, each conforming application shall include the
	header <Cversion.h> before any other header specified by this
	standard is included.

	If an application includes 
		#define _STD_C_REVISION 1990
	before any header specified by this standard, the compiler shall
	accept the language defined by ISO/IEC JTC-1 9899:1990.

	If any other value is specified, or the define is excluded, the
	result is implementation-defined.  The means by which the
	two versions are differentiated is unspecified.

	Rationale:

	The reader should note that an implementation conforming to this
	(the 1992) standard is required to accept the older C language.
	However, this does not make any backwards requirement on an 
	implementation claiming conformance to the 1990 standard, nor
	on any application written to conform to the 1990 standard,
	as long as it uses the 1990 standard compiler.  If the user
	wishes to use the 1992 complier with 1990 source code, a
	means to do so, with a one-line change to the application, is
	provided.  It is expected that many (most) applications written
	to the 1990 standard will be operate properly in the 1992 
	environment, but a mechanism is provided for the exception.

	It is expected that in future revisions, support for one or
	two previous revisions will be carried forward, but that not
	all previous revisions will be supported.  

(My comment: the header probably isn't needed until such time as a new
syntactic construct that could interfere with a user-defined identifier
is defined.)

Mechanisms like this are being developed for POSIX; they vary in details
from that here because POSIX is being delivered as a rapidly arriving
series of amendments and revisions to the baseline standard (adding
chunks of functionality each time).  I would suggest following that
work, as we have found many things that don't work in practice, and seem
to be homing in on something that will.  (FYI:  SC22/WG15 has
specifically asked POSIX to deliver its materials in "bite sized"
chunks, but as rapidly as possible; it is expected that in conformance
to this request from the relevant ISO body that there will be some years
where there are more than one amendment to the base standard proposed
and approved.)