Re: Parsing templates as baseclasses

[Mark Mitchell <mmitchell@usa.net>]

>>>>> "Mike" == Mike Stump <mrs@wrs.com> writes:

    >> Date: Sun, 1 Mar 1998 17:02:45 GMT From: Mark Mitchell
    >> <mmitchell@usa.net>

    >> As we speak, I'm engaged in the process of redoing the
    >> cp/parse.y from scratch

    Mike> This is something that needs to be done.

    Mike> Do you understand the hard parsing issues with C++?  If you

Yes. 

    Mike> think the grammar in the standard is the be all end all in
    Mike> grammars, then I suspect there are things that you don't yet
    Mike> understand, and without that understanding, completing this
    Mike> project to the level of completeness that makes the project
    Mike> worthwhile will be hard.  Do you think the grammar in the
    Mike> standard just works?  If so, why?

I know very well that there are a host of ambiguities, and that the
grammar in the standard is not LALR(1).  In fact, I'm familiar with
all the problems you mentioned below.  It's those problems, and the
fact that g++ gets some of the wrong at the moment, that inspired my
work.  Jason and I have been discussing my proposed techniques in some
private email.  We've been debating my approach (still based on bison)
versus and a recursive-descent parser.

Of course, since C++ is not LALR(1) no pure bison approach will work.
In fact, no finite amount of lookahead will do.  As you know, there
are certain statements that could be either function or object
declarations, so it is occasionally necessary to do `trial parses' or
build multiple parse trees and pick the right one later, or something
like this.

My plan involves a hybrid approach, whereby bison is used to much of
the work, but where there will sometimes be recursive parsing calls to
do trial parses, or hand-parsing.  It is easy to make bison generate a
re-entrant parser, and it's possible to have bison parse certain
constructs "by hand", with a bit more work.

At present, I've still got some work to do.  However, the parser in
its current state uses no precedence declarations (one of the major
maintenance nightmares of the current parser, in my opinion), and is
down to a handful (literally) of conflicts that need to be resolved
correctly.

I've suggested that this hybrid approach will be simpler than a
completely by-hand approach, and will allow us to substitue
hand-written parsers as we find it necessary for speed, better
error-recover, of what have you.

Jason has pointed out that most (all?) vendors now use
recursive-descent parsers, and that they tend to provide better
error-recovery. 

At this point, I'm inclined to go a bit farther with my approach;
either I will hit an unanticipated technial snag, or suceed; in the
latter case, everyone will get a chance to see what I've done and
decide whether or not it is satisfactory.

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu