Path: utzoo!attcan!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.lang.c++
Subject: Re: Philosophy in designing C++
Summary: C++ is indeed experimental, and incompleteness does have its merits
Message-ID: <466@aber-cs.UUCP>
Date: 23 Dec 88 17:13:54 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Distribution: eunet,world
Organization: CS Dept., University College of Wales, Aberystwyth, UK
	(Disclaimer: my statements are purely personal)
Lines: 104

In article <9247@ihlpb.ATT.COM> nevin1@ihlpb.UUCP (55528-Liber,N.J.) writes:

# It is much harder to take something out of the language once people have
# written code dependent on it than it is to add a definition when a
# reasonable choice can be made on what that definition should be.

Yes, I agree. I *did* say that C++ is still very much an experimental
language.  Unfortunately a lot of people are using it (within AT&T as well)
as a production language (me too shortly :->). This is very valuable
experience, of course, but probably somebody will be in for some suprise
sooner or later...

On the other hand in some case BS *could* have clarified a little better his
thoughts, or at least given a range of directions.

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

# (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.

# 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. One example: C++ was designed not
to require a runtime implementation substantially more complex than that for
C, nor a compiler substantially smarter. Other example: Algol68, while
beautifully designed, was not designed for ease of compilation or
implementation, and this is surely one of the factors that hampered it.

# One of the faults of C is that it was designed to compile down to PDP-11
# assembler

Probably a mixed blessing: on one hand it caused some funny PDP-11 dependent
quirks, on the other hand the PDP-11 model turned out to be an eminently simple
and proper one, that could be easily mapped to many other architectures.

Now, think what would have happened had they used an 8086 as a base.... :->

# (ex: in K&R-1 C compilers all floating point numbers are promoted to
# doubles for the purposes of doing calculations).

Even the floating point quirk can be reinterpreted in hindsight as a way to
ensure that the compiler was simpler and maximum precision always maintained
by insisting that all arithmetic be performed in double, while allowing space
to be conserved by permitting a short float format.

# It may help in the short term, but in the long term the language tends to
# suffer.

# Note:  studying cfront behavior is not the way to resolve the
# ambiguities, either.  Try to use only the constructs which have
# well-documented interpretations, and be prepared to someday rewrite code
# that is strictly dependent on how your compiler does things.

Agreed 100%.

# Waiting a short while is a small price to pay in order to get a nice,
# usable, consistent language.  It beats the alternative of making rash,
# arbitrary, short-term decisions.

I agree on this. Stroustrup has done a fairly good job, even if the language
is quite complex.

CONLUSION

While you agree with the idea that indeed in C++ there are no answers (yet)
to some good questions, I think that (provided that it is recognized that
some of these dark spots may be simply the result of quite understandable
oversights) you are quite right to point out that this may be a good thing,
to avoid early committment to not (yet) well understood solutions.

On  the issue of C++ complexity, I'd like to discuss a good question:  is this
complexity inherent in the desired level of functionality for C++ or could
the design have been simpler?

I used to think the answer was "it could have been simpler", both as to
functionality and the way to express it. I am no longer so sure... Anybody
cares to comment on what could have been made more orthogonal or omitted as
redundant?
-- 
Piercarlo "Peter" Grandi			INET: pcg@cs.aber.ac.uk
Sw.Eng. Group, Dept. of Computer Science	UUCP: ...!mcvax!ukc!aber-cs!pcg
UCW, Penglais, Aberystwyth, WALES SY23 3BZ (UK)