Topic: ANSI C Mission Statement
Author: jim.fleming@bytes.com (Jim Fleming)
Date: 1995/08/02 Raw View
In article <3visn0$pl1@newsbf02.news.aol.com>, ffarance@aol.com says...
>
>> 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
@@@@@@@@@@@@@@@@@@@
Thanks for the great summary. I apologize for not having as broad a
base of knowledge in this area as yourself. I have been busy developing
C+@ for the past 10 years.
My primary interest is in the area of companion languages for C and
the interworking of C with other languages such as Java and C+@. I am
willing to help in any way that I can but have to warn you that I bring
a strong bias toward having C be "just C" and having C+@ be a cool cat.
They work very well together and the large mature reusable class library
coupled with the extensive libraries written in "straight C" are a
testimony to the fact that this works.
I may not be able to attend all of your meetings but I am willing to
help review documents, write documents, etc. I still write code, after
over 20 years and I enjoy new languages, approaches, etc. especially
when they can be discussed in an open forum with biases known in advance.
Besides C and C+@, I am interested in issues such as architecture neutral
execution environments and virtual "C machines". I do not know whether
the standards committee has ever considered defining a reference virtual
C machine to be added to the standard but that sort of thing may be an
interesting project.
Also, with the announcement of Plan 9 by AT&T Bell Labs (http://www.att.com)
there may be a rebirth of interest in C. Plan 9 does not use C++ and
focuses on some of the more big picture issues that UNIX (and C) missed.
The ANSI committee(s) may find the Plan 9 information to be useful...
Again, I appreciate the info and I look forward to your meetings. BTW,
when and where are the meetings...???
--
Jim Fleming /|\ Unir Corporation Unir Technology, Inc.
jrf@tiger.bytes.com / | \ One Naperville Plaza 184 Shuman Blvd. #100
%Techno Cat I / | \ Naperville, IL 60563 Naperville, IL 60563
East End, Tortola |____|___\ 1-708-505-5801 1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX) 1-708-305-0600
\__/-------\__/ http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|