Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.std.c
Subject: Re: Vendor representatives on committee
Message-ID: <1662@crdos1.crd.ge.COM>
Date: 20 Nov 89 16:44:50 GMT
References: <11134@riks.csl.sony.co.jp> <15217@haddock.ima.isc.com> <1643@crdos1.crd.ge.COM> <1989Nov17.205004.19236@cs.rochester.edu> <1653@crdos1.crd.ge.COM> <11645@smoke.BRL.MIL> <1989Nov20.124013.28617@algor2.algorists.com>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: GE Corp R&D Center, Schenectady NY
Lines: 47

In article <1989Nov20.124013.28617@algor2.algorists.com> jeffrey@algor2.ALGORISTS.COM (Jeffrey Kegler) writes:
| A number of postings has suggested that there is something unethical
| or immoral about advocating the particular interests of a specific
| vendor on the ANSI C committee, as opposed to the general public
| interest.

  I don't think that any vendor was able to push *individual* special
interests, at least to the detriment of the standard, because all the
other vendors would object. I do think there was some bias toward
eliminating features which would be hard to implement, and some were
(almost) added because they would aid optimization.

  Obviously if the user wrote a standard they might generate another
Ada, big and expensive to implement. They might not address areas which
have to be defined for portability. Therefore I don't feel that a
committee of all users would be productive.

  When I was on the committee (first two years) I was often the only
person representing an organization which did not sell computers or a C
compiler. I think the need for user representation was minimal. There
were a few features dropped because they were hard to implement, so be
it. Some things were slightly changed in definition to make
implementation easier, and that's a good thing. I confess, I've written
a few compilers, and I have a LOT of sympathy with the vendors.

  Honestly there are only a few places in which I feel that the
committee dropped the ball, and my opinion is that these are places in
which the wording is confusing, inexplicit, or obscure. 

  I find only one feature in the standard which is well documented and
which I think is inappropriate. I'm not going to discuss it in this
thread, it has been beaten to death before without changing the mind of
the committee. it is clearly a case of doing something for ease of
implementation which is not existing practice, breaks existing programs
and adds no useful functionality to the language. I don't like it, but
I wouldn't want the standard to fail because the vendors took the easy
way out on one issue.

  I think criticism of the committee because of vendor interest is very
hard to justify by any facts, and that anyone who didn't care enough to
participate either by being there or sending in comments should not
complain about the process at this point.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"The world is filled with fools. They blindly follow their so-called
'reason' in the face of the church and common sense. Any fool can see
that the world is flat!" - anon