Undelivered mail

[MAILER%ALASKA.BITNET at CUNYVM.CUNY.EDU]

Subject:  Re: Why I won't use ANSI C

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C at BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 7033
          for SXJVK at ALASKA; Fri, 11 Mar 88 23:24 AST
Received: by UWAVM (Mailer X1.25) id 4744; Sat, 12 Mar 88 00:23:30 PST
Date:         Thu, 10 Mar 88 22:45:09 GMT
Reply-To:     Info-C at BRL.ARPA
Sender:       Info-C List <INFO-C at NDSUVM1>
From:         Doug Gwyn <gwyn at brl-smoke.arpa>
Subject:      Re: Why I won't use ANSI C
Comments: To: info-c at brl-smoke.arpa
To:           Vic Kapella <SXJVK at ALASKA>

In article <933 at micomvax.UUCP> ray at micomvax.UUCP (Ray Dunn) writes:
>I could go on, I'll spare you though (whew!) except to say that I *do*
>believe that we should remember that Doug's position on the ANSI committee
>gives him a certain power, but *not* necessarily a superior opinion on the
>contentious issues we all discuss (argue? shout about? go to sleep over?...).

Thanks for your comments.

The one real advantage that participating in X3J11 has given me is that
I've heard all the arguments for changing = to := and the other such
ideas that keep popping up in this newsgroup many times before.  Some
topics, such as = vs. ==, have probably been sparked by magazine articles,
since the same old arguments keep getting repeated.

To give you some idea of what X3J11 is up against, of 717 public comments
from the first formal review, roughly 257 (that's 36%) were adopted in
some form.  The remaining 460 comments (64% of the total) had to be read,
understood, discussed, and explanations of why they were not adopted
had to be written.  The work kept the whole committee busy for many days.
It shouldn't be any wonder that some of us by this point have little
patience with the same suggestions that we've had to write rejection
rationale for over and over.

By the way, = vs. == was indeed considered by X3J11, but what can we do
about it?  If it were changed, the result could not reasonably be called
"C".  In fact, as I recall, most of us don't even think it should be
changed if it were feasible to do so.  The only approach that is at all
compatible with a large body of C code (but by no means all) would be
to introduce Boolean expressions and require that the control conditions
of if(), while(), for(), do..while() be Boolean expressions.  That would
solve the
    if ( a = 0 )
problem.  But it would break so much existing code that I for one am
sure that no such "C" standard [that requires a diagnostic when the
Boolean-expression constraint is violated] would be generally accepted.