Path: utzoo!attcan!uunet!husc6!cmcl2!rutgers!tut.cis.ohio-state.edu!osu-cis!att!ihlpb!nevin1
From: nevin1@ihlpb.ATT.COM (Liber)
Newsgroups: comp.lang.c++
Subject: Re: Philosophy in designing C++
Message-ID: <9281@ihlpb.ATT.COM>
Date: 28 Dec 88 01:13:57 GMT
References: <466@aber-cs.UUCP>
Reply-To: nevin1@ihlpb.UUCP (55528-Liber,N.J.)
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 73

In article <466@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
|On the other hand in some case BS *could* have clarified a little better his
|thoughts, or at least given a range of directions.

Is there a way to do this without committing yourself?  Anything that
Bjarne puts in writing we, the C++ public, tend to hold him to it.

|Nevin Liber writes:
|# The folks at GNU seem to be resolving ambiguities by deciding what is
|# better for the *compiler*, and not what is (necessarily) better for the
|# *language*

|I agree on this, but with one obvious qualification: it often turns out that
|not only simplicity of implementation is an important pragamatic
|consideration, but it also is often true that design features that afford a
|simple implementation are also the most elegant for a language.

Yes, but often true != always true.  In those cases where these two
differ, I'd rather go along with Bjarne (better for the language) than
with GNU (better for the compiler).

|# (as evidence, I point to the recent discussion on why G++ uses an LALR(1)
|# grammar, instead of using the language defined by the C++ book).

|Good evidence. In part however this reinforces my previous paragraph:  their
|arguments that BS could have paid a little more attention to making parsing
|easy are in my opinion well founded; maybe I am assuming too much, but it has
|been my impression that the syntax "problems" are result of oversight; after
|all it is fairly hard to anticipate all possible consequences of rules in the
|design of a language.

|While I have not given much thought to the issue, I don't see much to lose in
|slightly changing syntax in the hard spots for the benefit of a parser, like
|a LALR parser.

As Bjarne stated in the C++ book (Implementation Notes, p3):

"..., where there was a choice between simplifying the manual and other
documentation or simplifying the compiler, the former was chosen.  Great
importance was also attached to retaining compatibility with C; this
precluded cleaning up C syntax."

By changing to a LALR grammar, g++ has violated the C compatibility
constraint!  While this may not be important for users of g++, those of
us who develop commercial software (where g++ can't easily be used, due to
licensing constraints) need C compatability so that we don't have to
rewrite millions of lines of old C code (this is also a good selling
point for management :-)).

Also, by requiring an LALR grammar, you will be less inclined to adopt
new features which cannot be expressed in the grammar, even though the
feature might be better for the language.

|# Designing a language is very different process than designing a compiler
|# for a language.  Defining the language based on how you want to write the
|# compiler tends to lead to trouble.

|A cautionary note: I agree that you want to DEFINE the language so that it is
|independent of any particular implementation, but the DESIGN had better take
|into account the possible implementations.

I'm sorry if I lead you to the impression that language design should
take place in a vacuum.  Of course language design must take into
account implementation!  When the language starts to become dependent on
the implementation, the trouble starts.


IMHO, the design of C++ has many parallels to designing a class within C++.
Think of the language definition as the class interface and the compiler as the
implementation of the class.  The class definition should not depend on the
class implementation; the metaphor should also hold for the language design.
-- 
NEVIN ":-)" LIBER  AT&T Bell Laboratories  nevin1@ihlpb.ATT.COM  (312) 979-4751