Re: C++ intermediate representation.

First, off let me apologize a little. I can get carried away in my
opinions sometimes. A lot of respect must be extended to someone who
builds anything that works in practice, and C++ does quite a bit
better than that. I know that I will ever create anything that will
have the impact C++ has had.


In that light, the flaws in C++ should be considered minor. The
constructor syntax is just a personal peeve of mine, because it leads
one in a particular direction, and if one had stayed with the C
initializer syntax, other choices would have gone a different
direction also.


Bjarne Stroustrup wrote:


> The int(a); problem was indeed known and considered unsolvable by
> experts (not just me) at the time. Consequently, early C++ designs
> deemed redundant parentheses (as in int(a);) illegal, thus avoiding
> the declaration/cast ambiguity. Later, the LALR(1) C grammar
> appeared and I had to back off in the interest on C compatibility. I
> suspect that choosing C compatibility in this case was the wrong
> decision, but it seemed inevitable at the time.


This explanation makes perfect sense. The fact that C itself is hard
to parse, could easily have lead to simplifying assumptions at the
start of C++ design, such that the conflicts I would have expected to
see would have been pre-resolved. And, I certainly wouldn't argue
that redundant parenthesis are necessarily a good feature of C's
declaration syntax.


At some level, I think that means we shouldn't generally design
languages that use all the parsing power we have. That was one of the
strengths of Pascal; one could parse it with a simple LL(1) parser,
aside from one little issue with "..". That also made Pascal programs
simple to understand, since they weren't (syntactically) ambiguous.


We had some of the same issues with Yacc++. We wanted yacc
compatibility. However, the optional semicolons at the end of rules
make the language tougher to parse (and make error recovery harder).
If you disallow optional semicolons, yacc grammars are also LL(1).
Now, although we could parse LR(2) grammars, as allowing optional
semicolons would have made it, it seemed like a pointless extension,
as it does not make grammars more readable. Keeping the grammar LL(1)
seemed worthwhile. I try to maintain that LL(1) property as I add new
features to Yacc++. I'm pretty sure our current grammar is nearly
LL(1). The only thing which keeps it from being completely LL(1) is
that we don't use "reserved" words--that is keywords can also be used
as identifiers. (Even with the non-reserved word feature, the grammar
is still LALR(1) (and LL(2) I believe).)


-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------

Return to the comp.compilers page.
Search the comp.compilers archives again.