🚀 go-pugleaf

> From: jim.fleming@bytes.com (Jim Fleming)
> 
> Has anyone written a mission statement for ANSI C to cover the next 5
> years...???
> 
> Before everyone starts tossing in "// comments", new types like "bool",
> classes, and extensive integer declaration proposals, maybe there ought
> to be some sort of mission statement or a set of goals.
> 
> There are many directions that C can go...here are a few...while it
> might be difficult to capture all of the goals in a mission statement,
> it might be good to get a consensus about the general plan for the
> future...

Yes, they have.  In about a week (I'll post it) you can take a look
on the WG14 and X3J11 FTP site:

	ftp://ftp.dmk.com/DMK/sc22wg14/c9x/Revision*

for the document ``Project Proposal: Revision of C Language Standard
ISO/IEC 9899:1990''.  I've summarized the main points of the revision
charter below.  BTW, this document has been widely distributed and
summarized in the trade journals.

This charter wasn't just ``published'', but was developed, reviewed,
and refined over the past 2 years.  I seem to remember the 1993-12
meeting where everyone came up with a laundry list of everything they
might want.  That list was straw-voted (unofficial vote -- just to get
the sense of the committee) on about 50-ish items.  Here was the results
*then*:

In Favor   Against    Concept

18         0          Longer external names
18         0          Defect reports
17         2          C++ compatibility
15         1          Remove default int
14         0          Mandate float/lang double functions
14         1          Compound literals/designated int
14         1          Extended int range
14         2          Boole data types
14         3          // comments
14         3          Remove obsolete features
13         2          Strong enums
12         0          International identifiers
12         2          Type-safe linking
12         3          ALO's (Array-Like Objects)
12         3          In-line
12         5          Arbitrary declarations (decl's anywhere)
10         1          Library clean up
10         5          Overloading
10         6          Complex
9          1          Char set improvements
9          2          IEEE FP (floating point)
9          3          Distributed (discontiguous) objects
9          3          Range types
9          4          Classes in C
9          4          Enum - extra commas
9          4          Restrict
9          5          True modules (packages)
9          6          References
8          3          VLA (Variable length arrays)
8          1          Better stdio (Chris Torek)
7          3          Bit length
7          4          Constructors/destrutors
6          3          Data parallel (DPCE)
6          6          X3H5 directives - control parallelism
6          7          Statement functions
5          3          Parallel I/O
5          3          Zero size object
5          4          LIA/CLID (WG11)
5          9          New operators
4          0          POSIX locale definition
4          1          Iterators
4          6          Remove float/lang double functions
4          6          Sets
3          3          ISO 10646
3          3          Namespaces
3          6          Debugging support
3          8          Exception handling
3          11         Nested functions
2          4          Auto mangement of dynamic structures - alloca
2          6          Fixed point arithmetic
1          6          Label as a data type
1          9          Logarithmic data types
1          11         Dynamic casts
1          15         Templates
0          9          Garbage collection
0          17         Multiple inheritances

I think this information has been published already (several times)
in trade journals.  BTW, this list isn't what we are *required* to
include, only a sense of what people are interested in.  Of course,
adding any feature requires a lot of work, so you need to have at
least one focal point, i.e., a person that is interested and has
the long-term commitment (several years), for each topic.

You'll find the much of the work falls into the following categories:

	- X3J11.1 NCEG (Numeric C Extensions Group) that spent 5 years
	(1989-1994) developing numeric (and related) features.  They
	issued this as a Technical Report recently.  A TR doesn't carry
	the weight of a Standard, but it is a recommendation for certain
	practices (in this case, numeric practices in C).  The reason
	NCEG was started was that there were features we wanted to add
	into C89, but couldn't get them into ANSI C because we were
	running out of time OR the feature was still being developed
	within the industry.  Of the list above, the following were
	part of the NCEG work (X3J11 members: pardon me if I got
	one or two wrong here):

		ALO's (Array-Like Objects)
		Bit length
		Boole data types
		Complex
		Compound literals/designated int
		Data parallel (DPCE)
		Distributed (discontiguous) objects
		Extended int range
		Fixed point arithmetic
		IEEE FP (floating point)
		Iterators
		LIA/CLID (WG11)
		Library clean up
		Mandate float/lang double functions
		Overloading
		Parallel I/O
		Remove float/lang double functions
		Restrict
		VLA (Variable length arrays)
		X3H5 directives - control parallelism

	About 12 of these made it into the technical report
	in some form or another.

	- Language independent features (e.g., arithmetic,
	data types, internationlization, etc.) that we are
	required to investigate at the ISO level (SC22
	requires this).

	- C++ compatibility features.  This ranges from the
	simple (e.g., choosing a common syntax for a Boolean
	data type) to the complex (e.g., classes).  C9X does
	not plan on incorporating C++.  The line between
	C and C++ is ``as close as possible, but no closer''.
	C9X may choose to incorporate the ``well-defined,
	efficient subset'' of C++.  SC22 (and ANSI, I think)
	requires C and C++ not to diverge on common issues.
	For example, features with the same functionality,
	conceptual model, and semantics, should have the
	same syntax.  However, features with different conceptual
	models (and, certainly, semantics) would likely have
	different syntax just to avoid ambiguous syntax.
	A good example of this is designated initializers and
	compound literals (see the FTP site for the proposal),
	a concept borrowed from Fortran and BLISS, versus
	C++ constructors.

Again, much of this has already been published in trade
publications (DDJ, C/C++ Users Journal, etc.).

> Sample Partial Mission Directions
> 
> 1. C grows up to be like C++
> ...
> 
> 2. C settles down as a great high-level assembly language
> ...
> 
> 3. C becomes ideal companion language for other high-level languages
> ...
> 
> 4. C requires very little change and just needs a few tweaks
> ...

The committee uses the following old (the first 6 are from ANSI C)
and new guiding principles.

	1.  Existing code is important, existing implementations
	are not.
	2.  C code can be portable.
	3.  C code can be non-portable.
	4.  Avoid ``quiet changes''.
	5.  A standard is a treaty between implementor and programmer.
	6.  Keep the spirit of C.
	7.  Support international programming.
	8.  Codify existing practice to address evident deficiencies.
	9.  Minimize incompatibilities with C90.
	10.  Minimize incompatibilities with C++.
	11.  Maintain conceptual simplicity.

The following are highlights from the recommended scope of the
proposed standard:

	Areas to which we intend to look when revising C include
	(in *no* particular order):

	1.  Incorporate Amendment 1.
	2.  All tehnical corrigenda and records of response.
	3.  Future directions in curent standard.
	4.  Features current labeled obsolescent.
	5.  Cross-language standards groups work.
	6.  The evolution of C++.
	7.  The evolution of other languages particularly with
	regard to interlanguage communication issues.
	8.  Other papers and proposals from member delegations,
	such as the numerical extensions Technical Report being
	proposed by X3J11.
	9.  Other comments from the public at large.
	10.  Other prior art.

> The four missions or approaches thumb-nailed above are not necessarily
> mutually exclusive. Maybe a poll needs to be taken to determine where
> people feel the ANSI C committee should "steer" the language. As a
result
> of this poll, maybe a single mission statement can be developed to
> allow people working on the ANSI committee to have some sense for what
> the general population thinks.

C has several groups that ``steer'' it: ISO JTC1 (ISO joint technical
committee - information technology), ISO JTC1/SC22 (programming
languages, their environments, and system software interfaces),
ANSI X3 (information technology), and the parent bodies of from other
countries (I don't know their organizations names), it addition to
comments from the public.

While we have many liaisons that inform us of other activies
(including people that monitor Usenet), it is not up to ANSI to
poll people -- in fact it is the other way around.  If you care about
what is going on, you should contribute technically to ANSI or
other national bodies via comments, papers, proposals, and/or
meeting attendance.  For example, several papers were submitted
by Richard Stallman, yet he didn't attend meetings nor was he
a member.  In fact, almost all the submissions of C9X revision
proposals (see FTP site for more into) that come from the public
at large are from people that aren't able to attend or become
a member, but are able to write a proposal -- the proposal for
the "__FUNC__" feature is from the public.  My guess is that it
has a good chance of being included because: (1) it was within
the guidelines above, (2) it was submitted according to the
C9X submission guidelines (see FTP site), (3) it included a
coherent paper describing the feature, (4) the author followed
up on the proposal, i.e., he revised the proposal based upon
comments received from the committee and others.

Your simple solution here is to read the information on the
FTP site concerning submission guidelines, the revision charter,
and the existing work in the area you have interest.  After that,
you can compose your comments and/or proposal and submit them
according to the submission guidelines.  After that you should
be prepared to respond to comments/criticism and revise your
proposal.

> Before everything but the kitchen sink is dropped into ANSI C, maybe
> we should discuss where C fits in the coming years...

It's an ongoing discussion.  You are welcome to participate via
comments, papers, and/or attendance.

-FF
-------------------------------------------------------------------
(``I only use AOL for reading netnews.'')
Frank Farance, Farance Inc.
E-mail: frank@farance.com, Telephone: +1 212 486 4700
ISO JTC1/SC22/WG14 & ANSI X3J11 (C Programming Language) Project Editor