🚀 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.

In article <11635@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
>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).

My point was not so much that X3J11 didn't do anything to C, but that they
didn't do very much that *some* existing implementation hadn't already done.
The unsigned-arithmetic rules, for example, existed in production compilers
well before X3J11 adopted them.  (There is a common syndrome in which X3J11
gets blamed for "inventing" anything that wasn't in the Unix C compilers,
but there have been other C compilers in the world for over a decade now.)
Prototypes and `const' were a borderline case, but early versions of C++
were pretty close to C and I think they were right in deciding that the
experience could be read across.  I believe the locale stuff existed at
HP.  w_char I am not sure about.  But overall, almost everything in ANSI C
is based on prior experience with C or C derivatives *somewhere*, and the
few things that were invented out of whole cloth -- notably `noalias' and
trigraphs -- were conspicuously poor ideas (in the case of `noalias',
sufficiently so to get it removed).

Although I'm not as happy with C++ as I used to be, I have little quarrel
with the idea of standardizing things that have been implemented and are
used successfully **in C++ or a derivative**.  I might think that feature
X is a dumb idea, but that's another question.  The numbers Bjarne cites
make it clear, in particular, that templates are well understood and are
appropriate for consideration by X3J16.

What concerns me is exception handling.  The article I was originally
responding to had a distinct air of "we're going to standardize something
like Bjarne's proposal; if we don't like it, we'll tinker with it until
we do".  This is why I hoisted storm warnings. :-)  I'm not convinced
that this feature has had enough implementation and use in C++ to be a
legitimate candidate for standardization at all -- confidence in the people
who designed it is not a substitute for real experience -- and committee
modifications to it are an invitation to disaster.  Storm warnings don't
mean that your house *will* blow down; they just denote cause for concern.
-- 
"I don't *want* to be normal!"         | Henry Spencer at U of Toronto Zoology
"Not to worry."                        |  henry@zoo.toronto.edu   utzoo!henry

>>>>> On 19 Nov 90 19:51:28 GMT, henry@zoo.toronto.edu (Henry Spencer) said:
	...
HS> What concerns me is exception handling.  The article I was originally
HS> responding to had a distinct air of "we're going to standardize something
HS> like Bjarne's proposal; if we don't like it, we'll tinker with it until
HS> we do".  This is why I hoisted storm warnings. :-)  I'm not convinced
HS> that this feature has had enough implementation and use in C++ to be a
HS> legitimate candidate for standardization at all -- confidence in the people
HS> who designed it is not a substitute for real experience -- and committee
HS> modifications to it are an invitation to disaster.  Storm warnings don't
HS> mean that your house *will* blow down; they just denote cause for concern.
HS> -- 
--

However, one would assume that other languages (Clu, Ada, Lisp, Mesa,
Module-2+ and Modula-3) have had exception handling, some of them for
years. Certain the design rational of those languages could be applied
to C++?

Henry Spencer at U of Toronto Zoology writes:

 > What concerns me is exception handling.

That is indeed a legitimate cause for concern. I share it up to a point.
It is the least tried aspect of the language as currently defined and
the one we ought to worry the most about.

We built partly on experience from the Clu, Modula2+, Modula3 sequence
of languages, partly on experience with faking exceptions in C++, and
partly on an experimental C++ with exception handling implementation
at Sun. So even though we don't have as much experience as we would
like we are not without practical experience with exceptions handling
in the context of C++.

There was another concern: There was a strong push from some users and
from some implementors: Agree on something NOW or else we will go our
own way. Caught between a rock and a hard place it seemed most sensible
for us all to agree to do the same thing. Anything else would guarantee
divergence.

I would have preferred a couple of years to experiement with exception
handling on a larger scale, but you can't always get exactly what you
want. People were NOT willing to wait with standardization and people
were NOT willing to define C++ without exception handling.

In article <30021@boulder.Colorado.EDU> grunwald@foobar.colorado.edu writes:
>HS> What concerns me is exception handling...  I'm not convinced
>HS> that this feature has had enough implementation and use in C++ to be a
>HS> legitimate candidate for standardization at all ...
>
>However, one would assume that other languages (Clu, Ada, Lisp, Mesa,
>Module-2+ and Modula-3) have had exception handling, some of them for
>years. Certain the design rational of those languages could be applied
>to C++?

The design philosophy, yes.  But *details are critical* in language design.
This is why it is so important to have *actual experience* with a feature,
in the language in question or a very close relative.  There is a big
difference between being able to say "something somewhat along these lines
ought to be workable, if we can get the details right" and being able to
say "we've proved that this exact design works".
-- 
"I don't *want* to be normal!"         | Henry Spencer at U of Toronto Zoology
"Not to worry."                        |  henry@zoo.toronto.edu   utzoo!henry