🚀 go-pugleaf

 rms@AI.MIT.EDU (Richard Stallman) writes
(in reply to a message from Henry Spenser):

 >    Ah, don't you just love language design by committee?  Especially
 >    when the committee throws out the "prior art" rule?  X3J11 showed
 >    commendable restraint in what they did to C, but there are storm
 >    warnings out for C++...
 > 
 > This spirit of careless incompatibility can be traced back to
 > Stroustrup.  Didn't he change the behavior of struct and union,
 > breaking almost all C programs?  Make an ambiguous grammar?

Before this degenerates further it might be useful to mention a few things.

X3J11 did indeed show restraint in what they did to C and I hope X3J16
will show similar restraint. It should be remembered that X3J11 did do
a few interesting things to C. Notably it added `const,' prototypes
(both adapted from C++), locale in libraries, w_char, the rules for
unsigned arithmetic, etc. (in such cases C++ has followed ANSI C).
Like C, C++ was at the point of standardization not in a state where
simple rubber stamping would make an acceptable standard.

In particular, the proposal to standardize C++ (from HP) explicitly
mentions the need to add templates and exception handling; both of
which have now been voted in. In both cases SOME prior art existed
both in C++ and in similar languages. In the case of templates X3J16
found 3 independent implementations and well over half a million
lines of code in use.

I don't see any signs of a ``spirit of careless incompatibility'' in
X3J16 nor could I see how such a thing could originate from me.

I am not aware of a  having ``change(d) the behavior of struct and union,
breaking almost all C programs.'' In fact, nothing C++ does to structs
or unions break any C programs. I suspect rms is misinformed.

The C++ grammar is indeed not LALR(1). The language extensions that
caused that are from 1982/1983. That is, before X3J11 was convened and
before an LALR(1) grammar for C was known. That the C++ grammar is not
LALR(1) is an inconvenience and X3J16 is looking into what can be done
to make the definition of C++ more amenable to formal parser techniques.
It should be remembered though that retrofitting a simple LALR(1)
grammar would break C++ code and X3J16 would be sensitive to accusations
of having broken code. Note that this grammar problem does not imply
a C/C++ incompatibility and that it stems directly from the desire
from making user-defined types notationally equal to built-in types in
C++ (rather than making do with the simple `struct s' and `union u'
notation from C). I think that my design choices in this area traded
implementor convenience for user convenience. It would have been nice
if I had found a way to inconvenience neither group, but I didn't.

I would consider it naive to expect a work of the magnitude of C++ to
be 100% compatible to C. C++ is a separate language from C. 100%
compatibility was not a C++ design aim (remember C didn't even have
prototypes when C++ was first put into use), ``no gratuitous
incompatibilities'' was the aim. I consider that aim met with more
success than most users expect or are aware of. For details see
chapter 18 (``Compatibility'') of the ARM or the paper I wrote for
``The C++ Report'' with Andrew Koenig: ``C++ - As close to C but
no closer.'' If you want 100% C compatibility use a C compiler.
If you are willing to remove anachronisms from your code (typically
just adding function prototypes and removing C++ keywords used as
identifiers will do the job) you can try C++. If you have a C++
compiler that carefully implements the language as defined by
the ARM I suspect you'll be pleasantly surprised with the degree
of compatibility.

Finally, we have yet to see an example of ``design by committee''
in X3J16. Templates and exception handling were designed by me
(helped by Andrew Koenig in the case of exception handling).
Naturally, this does not guarantee good design, but it is not
design by committee.