From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Mitchell To: mrs@wrs.com (Mike Stump) Cc: egcs@cygnus.com Subject: Re: Parsing templates as baseclasses Date: Mon, 02 Mar 1998 20:02:00 -0000 Message-id: <199803021911.TAA28112@quickstep.stanford.edu> References: <199803030157.RAA02370@kankakee.wrs.com> X-SW-Source: 1998-03/msg00060.html >>>>> "Mike" == Mike Stump writes: >> Date: Sun, 1 Mar 1998 17:02:45 GMT From: Mark Mitchell >> >> 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