[comp.lang.c] standards development process

henry@utzoo.uucp (Henry Spencer) (04/09/88)

> Future language standardizations should have more representation by
> users, and this should be required by ANSI...

How do you propose that they should require this?  Forbid standardization
without adequate user representation?  In practice this would lead to
very few standards being written.  There is NO LAW against more users
getting involved in ANSI standardization work!!  The problem is that
few of them bother.  Without users who actively care and get involved,
the situation is not going to get better; with them, the problem will cure
itself without changes to the rules.  ANSI standards committees are quite
explicitly open to anyone who wants to join.  If you care so much, why
weren't you in X3J11?  (I don't see your name in the membership list that
came with the second-public-comment draft.)

Remember that participation in something like X3J11 takes non-trivial
amounts of time and money, particularly time.  How many users are going
to get assigned to such things as part of their job?  Without that, it
really is quite difficult to find the time.  I am *not* an X3J11 member
partly because I can't find the time to do a proper job of it; it's not
easy to find the time for the peripheral involvement that I do have.
-- 
"Noalias must go.  This is           |  Henry Spencer @ U of Toronto Zoology
non-negotiable."  --DMR              | {allegra,ihnp4,decvax,utai}!utzoo!henry

purtill@faline.bellcore.com (Mark Purtill) (04/11/88)

In article <> henry@utzoo.UUCP writes:
>> Future language standardizations should have more representation by
>> users, and this should be required by ANSI...
>
>How do you propose that they should require this?  Forbid standardization
>without adequate user representation?  In practice this would lead to
>very few standards being written.  There is NO LAW against more users
>getting involved in ANSI standardization work!!  The problem is that
>few of them bother.  

One of the reasons that few people bother is that ANSI charges large
sums of money for copies of the standard; last I heard, it was on the
order of $50.  I think it costs even more to actually join X3J11 (altho 
I'm not sure).  If ANSI would allow net distribution, they probably get
a lot more response.

(Actually, early on someone was sending out free copies of the standard;
I've got one, but its on the order of two years old, and I've been told
X3J11 will ignore comments not based on the latest standard.  It didn't
have such stuff as noalias in it anyway...)

^.-.^ Mark Purtill
((")) purtill@math.mit.edu

henry@utzoo.uucp (Henry Spencer) (04/12/88)

> One of the reasons that few people bother is that ANSI charges large
> sums of money for copies of the standard; last I heard, it was on the
> order of $50.  I think it costs even more to actually join X3J11 (altho 
> I'm not sure)...

X3J11 committee membership costs some nominal amount, $100 or something
like that, after which things like drafts are free.  In fact, being a
member means getting vast mounds of paper for free.  The problem is that
you are supposed to read it all.

The actual cost of being a committee member is mostly (a) expenses for
attending meetings, and (b) the time spent reading (and thinking about)
endless documents.  As I recall, you have the right to vote only if you
attend the (quarterly) meetings fairly regularly.  And you will put your
foot in your mouth with some frequency if you don't make some effort to 
read the endless reams of proposals, comments, and drafts.

Nobody who hasn't tried it can possibly imagine what a grind it is to do
a careful, thorough, line-by-line reading of the latest draft of a complex
technical document, especially when you have already seen 57 earlier drafts
and are thoroughly sick of it.

People who read comp.lang.c will, however, have some grasp of what a grind
it is to have to read, comment on, and shoot down the same old dumb ideas
for the 57th time.  Standards committees have to do a lot of that too.

> If ANSI would allow net distribution, they probably get a lot more response.

There is a real and legitimate debate about (non)availability of machine-
readable copies of the document, but I would observe that ANSI has some
cause for restricting distribution to those who are motivated enough to
make an effort to obtain the document.  It has never been terribly hard
to participate in X3J11 (or whatever) if you really want to.
-- 
"Noalias must go.  This is           |  Henry Spencer @ U of Toronto Zoology
non-negotiable."  --DMR              | {allegra,ihnp4,decvax,utai}!utzoo!henry

lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (04/12/88)

Henry Spencer writes:

>> I (Larry Cipriani - that's pronounced sip ree ah knee) write:
>> Future language standardizations should have more representation by
>> users, and this should be required by ANSI...

>How do you propose that they should require this?  Forbid standardization
>without adequate user representation?

Yes.

>In practice this would lead to very few standards being written.

Maybe so, then again, maybe not.  I don't think predictions like
this can be made with certainty.  If so, I can accept it.

>There is NO LAW against more users
>getting involved in ANSI standardization work!!  The problem is that
>few of them bother.

As another writer said in response, there are many perfectly good
reasons why users don't get involved, cost is a big one, lack of
time another.

>Without users who actively care and get involved,
>the situation is not going to get better; with them, the problem will cure
>itself without changes to the rules.

So far language standards have resulted in such ugly languages.
How is that any better? I'd rather not have portability than use ANSI-C.
Actually, as long as noalias was removed I would be content (but not
overjoyed) to use ANSI-C.  Consider the recent FORTRAN-8X standards,
by all accounts I've read the vendors are really screwing up FORTRAN.

>ANSI standards committees are quite
>explicitly open to anyone who wants to join.

Glad to hear it.  Part of the problem though is that people don't
even know that the standardization of something or other has started.
Maybe an alternative to requiring user participation, is that the
standardization effort should be advertised in a way that reaches
most of the users.  At least they will know about it.  I bet only
20% of the C users ever heard of ANSI-C.

>If you care so much, why weren't you in X3J11?  (I don't see your name
>in the membership list that came with the second-public-comment draft.)

AT&T was already represented, and it would be inappropriate for me to
do so independently.

-- 
Larry Cipriani, AT&T Network Systems and Ohio State University
Domain: lvc@tut.cis.ohio-state.edu
Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (weird but right)

barmar@think.COM (Barry Margolin) (04/12/88)

In article <10314@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes:
>As another writer said in response, there are many perfectly good
>reasons why users don't get involved, cost is a big one, lack of
>time another.

Why is this?  Why are companies that produce compilers richer than
companies that write everything else?  If a company has a vested
interest in producing portable C programs then it should be worth
$100/year and some person-time to make sure that its needs are
represented in the standard.  If by "users" you mean individuals,
rather than companies, I think this effect is by design; one purpose
of the membership fee is to prevent complete randoms from joining,
making sure that committees are made up of those whose livelihood is
significantly impacted by the lack of a standard (in the case of
languages, this generally includes vendors of compilers and vendors of
programs written in that language).

>>ANSI standards committees are quite
>>explicitly open to anyone who wants to join.
>
>Glad to hear it.  Part of the problem though is that people don't
>even know that the standardization of something or other has started.
>Maybe an alternative to requiring user participation, is that the
>standardization effort should be advertised in a way that reaches
>most of the users.  At least they will know about it.  

Communications of the ACM has a regular column that reports on
computer-related standards activities.  I believe that IEEE Computer
and ComputerWorld may also have similar columns.  What more can be
done, a mass mailing?

>							I bet only
>20% of the C users ever heard of ANSI-C.

I'm sure that most books on C in the last few years mention the
standardization.  For example, Harbison & Steele mentions it
throughout the book.  There have been articles in magazines such as
Byte and Computer Languages.  Unfortunately, personal phone calls to
everyone who has purchased Turbo-C are not feasible :-)

Barry Margolin
Thinking Machines Corp.

barmar@think.com
uunet!think!barmar

gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/12/88)

In article <10314@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes:
>As another writer said in response, there are many perfectly good
>reasons why users don't get involved, cost is a big one, lack of
>time another.

Now, hold on.  If someone doesn't care enough to get involved, why
should any attention be paid to their desires?  I've been known to
spend my own money to attend meetings and conferences, and I'm not
exactly rolling in money myself (and I certainly don't have any
spare time!).  At the very least, concerned individuals could
communicate with the X3J11 committee or its individual members,
and many have indeed done so, thereby helping shape the proposed
Standard.  I don't have much sympathy for those who think X3J11
should have made a special effort to seek out their opinions
(except possibly for Dennis Ritchie, who appears to have been kept
pretty much apprised of X3J11 developments).

>I bet only 20% of the C users ever heard of ANSI-C.

Only the 20% who care enough about the language to have opinions
worth listening to, I bet.  The ANSI C standardization effort has
been publicized for years in columns in trade journals and elsewhere.
It has hardly been a secret.  Do you think X3J11 should have bought
space for ads in the comics pages of major newspapers in order to
reach the rest of the C programmers?

rns@se-sd.sandiego.NCR.COM (Rick Schubert) (04/13/88)

In article <10314@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes:
> ...
>Actually, as long as noalias was removed I would be content (but not
>overjoyed) to use ANSI-C.  

When and if there is an ANSI C Standard that contains "noalias", feel
free to write programs that do not contain the token "noalias".

-- Rick Schubert

daveb@laidbak.UUCP (Dave Burton) (04/13/88)

In article <7666@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
|The ANSI C standardization effort has
|been publicized for years in columns in trade journals and elsewhere.
|It has hardly been a secret.  Do you think X3J11 should have bought
|space for ads in the comics pages of major newspapers in order to
|reach the rest of the C programmers?

That certainly would have been appropriate for noalias, et al. ;-)
-- 
--------------------"Well, it looked good when I wrote it"---------------------
 Verbal: Dave Burton                        Net: ...!ihnp4!laidbak!daveb
 V-MAIL: (312) 505-9100 x325            USSnail: 1901 N. Naper Blvd.
#include <disclaimer.h>                          Naperville, IL  60540

lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (04/14/88)

In article <1509@se-sd.sandiego.NCR.COM> rns@se-sd.sandiego.NCR.COM (Rick Schubert) writes:
>In article <10314@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes:
>> ...
>>Actually, as long as noalias was removed I would be content (but not
>>overjoyed) to use ANSI-C.  
>
>When and if there is an ANSI C Standard that contains "noalias", feel
>free to write programs that do not contain the token "noalias".

Certainly, but I will have to deal with code that I did not
write that contains "noalias".  After all, most of a programmers
work is in maintenance not development.

-- 
Larry Cipriani, AT&T Network Systems and Ohio State University
Domain: lvc@tut.cis.ohio-state.edu
Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (weird but right)

jwhitnel@csi.UUCP (Jerry Whitnell) (04/14/88)

In article <1509@se-sd.sandiego.NCR.COM> rns@se-sd.sandiego.NCR.COM (Rick Schubert) writes:
>In article <10314@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes:
>> ...
>>Actually, as long as noalias was removed I would be content (but not
>>overjoyed) to use ANSI-C.  
>
>When and if there is an ANSI C Standard that contains "noalias", feel
>free to write programs that do not contain the token "noalias".

Yes, but what about the programmers who write the code that I'll be
maintaining?  How can I make sure they don't use noalias as well?  Shoot
them?

>
>-- Rick Schubert

Jerry Whitnell				Been through Hell?
Communication Solutions, Inc.		What did you bring back for me?
						- A. Brilliant

dsill@NSWC-OAS.arpa (Dave Sill) (04/14/88)

Larry Cipriani writes:
> Future language standardizations should have more representation by
> users, and this should be required by ANSI...

Henry Spencer replies:
>How do you propose that they should require this?  Forbid standardization
>without adequate user representation?

Does the phrase "No taxation without representation" ring a bell?  Oh
that's right, Henry's Canadian.

>There is NO LAW against more users getting involved in ANSI
>standardization work!!  The problem is that few of them bother.

It's not that they don't bother.  Compiler-marketing companies
obviously have more at stake in the standardization than the typical
company that uses their compilers.  Hence, they are more willing to
support an employee on a standards committee.

It's not quite as easy to be on a committee as some have suggested.
Yes, the membership fee is nominal; and yes, everyone is eligable.
But the cost of attending meetings all over the country is more than
most individuals can afford.  Then there's the time that must be
spent, probably 10-20 hours/week if you want to do it right, maybe
even more.

I'm not ready to be a martyr for an ANSI standard.  There are much
more worthwhile things one can do.  (Support the Free Software
Foundation, Amnesty International, WHO, et cetera.) 

Are comments the only form of input a non-ANSI member has to an ANSI
committee/standard?  The comments are a good idea, but X3J11 is not
bound use them.  It seems like a public ballot would be reasonable.
Isn't that what IEEE does?

=========
The opinions expressed above are mine.

"A point comes when enough money has been invested in a certain
 paradigm that something has to be truly revolutionary to throw
 it over."
					-- Bill Joy

rns@se-sd.sandiego.NCR.COM (Rick Schubert) (04/15/88)

In article <10511@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes:
+In article <1509@se-sd.sandiego.NCR.COM> rns@se-sd.sandiego.NCR.COM (Rick Schubert) writes:
++In article <10314@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes:
+++ ...
+++Actually, as long as noalias was removed I would be content (but not
+++overjoyed) to use ANSI-C.  
++
++When and if there is an ANSI C Standard that contains "noalias", feel
++free to write programs that do not contain the token "noalias".
+
+Certainly, but I will have to deal with code that I did not
+write that contains "noalias".  After all, most of a programmers
+work is in maintenance not development.

I was responding to your claim that you would use ANSI C if it didn't
contain "noalias" but you would not use it if it did; I did and do maintain
that if the presence of "noalias" was the determining factor for you, that
you could program in ANSI C--, which would be ANSI C - "noalias".  I think
that dealing with other programmers' code containing "noalias" confuses the
issue.  When you say that you will refuse to use ANSI C if it contains
"noalias", what do you plan to do?  Use existing C compilers? or use another
language?  That wouldn't address the issue of what you do with other people's
ANSI C programs.  Do you avoid them altogether?  I guess so, if you do not
plan on using ANSI C.  But if you're going to avoid them altogether, you
still have an independent choice to make for your own programs.  And for
this choice I say: "feel free to write programs that do not contain the
token 'noalias'."

+Larry Cipriani, AT&T Network Systems and Ohio State University

Rick Schubert (rns@se-sd.sandiego.NCR.COM)

gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/15/88)

In article <12960@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes:
>Are comments the only form of input a non-ANSI member has to an ANSI
>committee/standard?  The comments are a good idea, but X3J11 is not
>bound use them.  It seems like a public ballot would be reasonable.
>Isn't that what IEEE does?

Restricting balloting to actively participating members is a good idea
for the same reasons as those that led our (USA) founding fathers to
set up a representative republic instead of a democracy.  (Let's not
discuss why the original plan was subverted in this newsgroup, please!)

friedl@vsi.UUCP (Stephen J. Friedl) (04/15/88)

In article <1510@se-sd.sandiego.NCR.COM>, rns@se-sd.sandiego.NCR.COM (Rick Schubert) writes:
> When and if there is an ANSI C Standard that contains "noalias", feel
> free to write programs that do not contain the token "noalias".

I am certainly not a |noalias| wizard, but it strikes me that Rick
might be premature here; those who understand |noalias| are well
encouraged to correct me.

While I may be free to not use |noalias| myself, I am required
to interface with the library, most of whose routines have arguments
declared with some permutation of |const| and/or |noalias|.  Because
of this I think I think I have to have some nominal awareness of
what these keywords do; the violent flamage against |noalias| leads
me to believe that just pretending they are not there will get me
into trouble.

Anybody?

-- 
Steve Friedl   V-Systems, Inc.   "Yes, I'm jeff@unh's brother"
friedl@vsi.com  {backbones}!vsi.com!friedl  attmail!vsi!friedl

throopw@xyzzy.UUCP (Wayne A. Throop) (04/15/88)

> dsill@NSWC-OAS.arpa (Dave Sill)
>> (Henry Spencer)
>>There is NO LAW against more users getting involved in ANSI
>>standardization work!!  The problem is that few of them bother.
> It's not that they don't bother.  Compiler-marketing companies
> obviously have more at stake in the standardization than the typical
> company that uses their compilers.  Hence, they are more willing to
> support an employee on a standards committee.

Dave's position doesn't make sense to me.  Don't companies that *use*
those compilers have a stake in the future portability of their code,
and thus have a very convincing motive to support employees on the
standards comittee?

The psychology of such consumer-oriented participation (or rather: lack
thereof) seems to me to be based on the "We'll live with whatever the
comittee comes up with." fallacy.  This fallacy seems to fit neatly into
the category of "not bothering".

(And by the way, many compiler-vendor representatives have much more
 reason to be conservative about feeping creaturism than do compiler
 users.  After all, they have to spend money to develop the feeping
 creatures that folks come up with.)

--
If the argument to .TH contains any blanks and is not enclosed by double
quotes, there will be dird-dropping-like things on the output.
                                --- Unix User's Manual, MAN(7) entry, BUGS
-- 
Wayne Throop      <the-known-world>!mcnc!rti!xyzzy!throopw

mike@arizona.edu (Mike Coffin) (04/15/88)

From article <1510@se-sd.sandiego.NCR.COM>, by rns@se-sd.sandiego.NCR.COM (Rick Schubert):
> ...  And for
> this choice I say: "feel free to write programs that do not contain the
> token 'noalias'."
> 
> Rick Schubert (rns@se-sd.sandiego.NCR.COM)

Two points:  First, you can't ignore noalias --- the interfaces to the
standard library functions are liberally sprinkled with with "noalias"
and "const noalias".  Unless you want to rewrite <stdio>, you had better
understand noalias.  Second, the reason that C is a beautiful example of
language design is that the ratio of power to complexity is so high.
Noalias adds nothing to the expressive power of the language, while
hugely increasing its complexity.






-- 

Mike Coffin				mike@arizona.edu
Univ. of Ariz. Dept. of Comp. Sci.	{allegra,cmcl2,ihnp4}!arizona!mike
Tucson, AZ  85721			(602)621-4252

meissner@xyzzy.UUCP (Michael Meissner) (04/16/88)

In article <12960@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes:
| Are comments the only form of input a non-ANSI member has to an ANSI
| committee/standard?  The comments are a good idea, but X3J11 is not
| bound use them.  It seems like a public ballot would be reasonable.
| Isn't that what IEEE does?

ANSI makes the rules, the individual technical commitee (X3J11 in this
case) doesn't.  The rules go something as follows:

    1)	A technical committee is formed for a specific purpose

    2)	The technical committee works until it has a draft for public
	review.

    3)	Said draft is sent out for public review, and published by ANSI.
	The first review period is ~4 months, and additional review
	periods are then 2 months.

    4)	Anybody interested writes their comments and sends them to the
	committee.

    5)	All letters received must be answered.  The answer either yes or
	no, but it must be answered.  If in doing so, any substantive
	changes are made to the document, go back to step 2 (editorial
	changes such as spelling mistakes, etc. don't count).

Additionally there is a review by the parent committee (X3).  I'm not
sure whether this is in parallel with the public review, or after the
public review.  To be on the X3 review, the cost is several thousand
dollars, and you have to promise to review all documents within two
weeks of getting it (and you have to review ALL ANSI X3 documents, on
things like tape formats, character sets, etc.).  Note that for a
technical committee and X3, each organization (ie, a company, government
agency, etc.) can only have one voting member at any one time, as well
as an alternate, who can only vote officially when the prinicipal member
is not present.

The highest level of review is the ISO level, where each country gets
one vote (it's standardization body).  C is going through the
standardization for ANSI (U.S.A standard) and ISO at the same time,
which is fairly common these days.

IEEE is a different standards body, and has quite different rules.  The
public balloting procedures are different, as well as the assumption
that each person votes as an individual, not as an organization
representative.  Also, IEEE tends to stress reaching concensus, rather
than 2/3 votes like ANSI does.  (I'm not as familar with IEEE voting
rules, as with ANSI, I do know the Pascal standard was delayed by at
least a year because it tried to be both an ANSI and an IEEE committee
at the same time).

Each system has it's pluses and minuses, but like anything else, once
you are in the system, you pretty much have to abide by the system's
rules.
-- 
Michael Meissner, Data General.		Uucp: ...!mcnc!rti!xyzzy!meissner
					Arpa/Csnet:  meissner@dg-rtp.DG.COM

gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/16/88)

In article <543@vsi.UUCP> friedl@vsi.UUCP (Stephen J. Friedl) writes:
>While I may be free to not use |noalias| myself, I am required
>to interface with the library, most of whose routines have arguments
>declared with some permutation of |const| and/or |noalias|.  Because
>of this I think I think I have to have some nominal awareness of
>what these keywords do; the violent flamage against |noalias| leads
>me to believe that just pretending they are not there will get me
>into trouble.

As the January 1988 draft was worded, I believe you're correct.
The intent was that "normal" programmers could ignore the type
qualifiers in the library interface specs and continue to use
the functions as they're accustomed to.  This is something we'll
have to fix next week.

lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (04/17/88)

>> = Larry Cipriani
> = Doug Gwyn

>>As another writer said in response, there are many perfectly good
>>reasons why users don't get involved, cost is a big one, lack of
>>time another.

>Now, hold on.  If someone doesn't care enough to get involved, why
>should any attention be paid to their desires?

Now, hold on.  Don't put words in my keyboard, I'm only citing reasons
why they don't get involved.

I recognize that their desires probably won't get any attention
unless they get involved.  If they should be considered or not is
another matter.  If they aren't considered, and X3J11 has done what
it thinks is a fine job, but the users hate it what will happen?
ANSI-C will fail.  I don't think X3J11 wants that, neither do I.

And why does the converse necessarily hold.  If someone cares enough
to get involved why should their desires get any attention.  What
if their ideas are so bizarre that they should not participate.  How
does X3J11 tell someone to bug off?  Who decides what is bizarre?
Me! Really, I don't know.

Maybe X3J11 should just close up shop and let Dennis Ritchie take
over the job if he wants it.

>The ANSI C standardization effort has
>been publicized for years in columns in trade journals and elsewhere.
>It has hardly been a secret.  Do you think X3J11 should have bought
>space for ads in the comics pages of major newspapers in order to
>reach the rest of the C programmers?

Well the first thing I read in the newspaper are the comics! :-)

The world of C programmers is not made up only of computer jocks.
Not all the excellent C programmers are programmers by profession.
Many of them are scientists in other fields, they read their own
journals and magazines not computing/computer trade journals.
I do think X3J11 should have made a special effort to publicize
at the start, not now though.

Don't assume that the people that aren't involved don't have
worthwhile opinions, and don't assume that the people that
are involved do have worthwhile opinions.  It is the latter
group that concerns me the most.  By standardizing C I expect
that C will be standardized, I don't expect that a new language
will be invented which is what is happening.  At this point ANSI-C
is so different than the C I know that I wouldn't call it C, maybe
D, but not C.

-- 
Larry Cipriani, AT&T Network Systems and Ohio State University
Domain: lvc@tut.cis.ohio-state.edu
Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (weird but right)

dsill@NSWC-OAS.arpa (Dave Sill) (04/19/88)

> Wayne Throop
>> dsill@NSWC-OAS.arpa (Dave Sill)
>>> (Henry Spencer)
>>>There is NO LAW against more users getting involved in ANSI
>>>standardization work!!  The problem is that few of them bother.
>> It's not that they don't bother.  Compiler-marketing companies
>> obviously have more at stake in the standardization than the typical
>> company that uses their compilers.  Hence, they are more willing to
>> support an employee on a standards committee.
>
>Dave's position doesn't make sense to me.  Don't companies that *use*
>those compilers have a stake in the future portability of their code,
>and thus have a very convincing motive to support employees on the
>standards comittee?

Yes, of course they have a motive.  They just don't have as strong a
motive.

Let's look at the vendor side.   The success of, say, Lattice's C
compiler probably has a direct influence on every employee of the
company.  Even Microsoft, with hundreds of other products, would feel
the pinch if their C compiler sales dropped significantly.  The PC
compiler market is very competitive; and the vendors have much at
stake and much to gain by being able to claim that their compiler is
the best.  They want things like `volatile' and `noalias' so they can
write mega-optimizing compilers to enter in The Big Benchmark Contest.

Now let's look at the user side.  The typical company (excluding C
compiler vendors, of course) has a much smaller stake in the compiler
wars.  They aren't going to have to lay off 50% of their employees
because they can't buy a C compiler that handles `volatile'.  Even the
`support the standard for portability reasons' argument doesn't hold
water: a standard will be created whether Company X supports a
committee member or not.

>The psychology of such consumer-oriented participation (or rather: lack
>thereof) seems to me to be based on the "We'll live with whatever the
>comittee comes up with." fallacy.  This fallacy seems to fit neatly into
>the category of "not bothering".

To an extent, this is true.  As I pointed out above, they just don't
have enough reason to support a committee position.

>(And by the way, many compiler-vendor representatives have much more
> reason to be conservative about feeping creaturism than do compiler
> users.  After all, they have to spend money to develop the feeping
> creatures that folks come up with.)

Yeah, right.  Just like automakers curse air-conditioning, FM radios,
power steering, et cetera.  A product is the sum of its features.

=========
The opinions expressed above are mine.

"Faith is believing what you know ain't true."
					-- Anonymous

franka@mmintl.UUCP (Frank Adams) (04/19/88)

In article <7666@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>Now, hold on.  If someone doesn't care enough to get involved, why
>should any attention be paid to their desires?

The following is an oversimplification, but I think it is basically accurate.

There are perhaps 100 organizations involved in writing C compilers.  Each
of these has considerable interest in the standard -- let us say 100 units
worth.  This gives us a total of 10,000 units of interest by compiler
development organizations.

There are perhaps 10,000 organizations using C compilers.  Each of these has
much less interest in the standard than the individual compiler writers --
let us say 10 units worth.  This still adds up to a total of 100,000 units
of interest by users -- ten times as much as the compiler folks.

But, it costs the equivalent of maybe 20 units of interest for an
organization to involve itself in the process.  So the applications
developers don't bother, and the process is dominated by the compiler
writers.

A further complication is that many of the larger applications development
organizations, who might indeed find it worthwhile to send a representative
from the applications side, are also compiler vendors; and the rules only
allow one representative per organization.

I don't have any answers here.  But there is a very real problem.
-- 

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108

throopw@xyzzy.UUCP (Wayne A. Throop) (04/20/88)

> dsill@NSWC-OAS.arpa (Dave Sill)
>> throopw@dg-rtp.UUCP (Wayne Throop)
>>Don't companies that *use*
>>those compilers have a stake in the future portability of their code,
>>and thus have a very convincing motive to support employees on the
>>standards comittee?
> Yes, of course they have a motive.  They just don't have as strong a
> motive.

Well, I agree that many people perceive this motive as "weak", but I am
convinced that they are mistaken.

> Even the
> `support the standard for portability reasons' argument doesn't hold
> water: a standard will be created whether Company X supports a
> committee member or not.

Quite right.  But, the standard may not represent anything that Company
X can use.  For example, it may invalidate too much code that X has
already written in K&R C.  Or it may mandate a lanaguage too large to be
implemented on the equipment that X uses.  Or it may mandate BCD
arithmetic that X's compiler vendors can only supply in criplingly slow
form.  Or it may incorporate features (dare I say "noalias"?)  (I dare,
I dare) which make it harder to understand the standard library
interfaces and hence make writing standard-conforming code far too
difficult.

All of these things are, I submit, potentially threatening to the
profitibility and even survivability of Company X.  The fact that X's
CEO doesn't see it that way simply means to me that X's CEO is wrong.

>>(And by the way, many compiler-vendor representatives have much more
>> reason to be conservative about feeping creaturism than do compiler
>> users.  After all, they have to spend money to develop the feeping
>> creatures that folks come up with.)
> Yeah, right.  Just like automakers curse air-conditioning, FM radios,
> power steering, et cetera.  A product is the sum of its features.

But even auto vendors argue against expensive features that they think
(for whatever reason) that customers don't want to buy.  Air bags, for
example.  Emissions controls.  5-mph bumpers.  These features exist
(when they do) by the demand of users, not vendors.  And the fact that
US automakers can compete at all against import vendors primarily
because they can offer to leave features OFF to save money or customize.

But to clarify: I wasn't trying to say vendors will always take the KISS
side of things.  Just that they sometimes do, and often have motive to.
As I understand it, "noalias" in particular was not proposed by vendors,
but by users who wanted a feeping creature.  I may be wrong about that.

--
And you may ask yourself  "Am I right? ... Am I wrong?"
And you may say to yourself  "MY GOD! ... WHAT HAVE I DONE?"
                        --- "Once in a Lifetime", Talking Heads
-- 
Wayne Throop      <the-known-world>!mcnc!rti!xyzzy!throopw

gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/24/88)

In article <10811@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes:
>At this point ANSI-C is so different than the C I know ...

How so?  It includes more than you are accustomed to, undoubtedly
(e.g. prototypes and type qualifiers), but it is substantially the
same language.  Most existing more-or-less portable C code should
continue to work under an ANSI C implementation with no change.
I expect that C compiler vendors will make every effort to supply
the same non-ANSI C extensions that their customers are already
using; for example, although <stdarg.h> is the new form for variadic
argument handling macros, most current implementations of <varargs.h>
will continue to be provided as extensions to the ANSI C environment.

Experiments wherein existing UNIX PCC-developed code has been
recompiled in an ANSI C environment have shown that most of it
works no worse than before.  Sounds like the same language to me.