> I've often wished that Bison's syntactic and semantic analysis phases were > more fully separated. However, this sounds like a major rewrite of vital > Bison internals. If someone tackles this over the summer, I hope we can > find a way to maintain a stable version of Bison in parallel. > > > I wish Bison was in C++... Joel, WDYT? This kind of changes would > > really benefit from moving to some simple, standard, portable, C++. > > Yeah, I know Paul, there's no such thing as portability, just sweat :) > > With a strong emphasis on *simple* C++, I agree. I don't want to scare > away developers by employing hardcore generic programming, multiple > inheritance, etc. I imagine a "C++ Don'ts" section evolving in HACKING.
Hi all, Another vote for improved C++ support, with some provisions. I've had satisfactory results with 'transforming' the lalr1 C-skeleton generated code and compiling as C++: pushing global tables into a parser class's global static variables, internal stacks and arrays managed as class members, leak-free memory management with constructor-destructor use, pure-parser and re-entrant transformations, exception catching (thrown from lexer) and clean-up. Now if this was done purely from C++ without 'extreme makeover' C-postprocessing, the result would be very clean. No inheritance is necessary, but some generic programming principles such as template specializations can be VERY helpful in defining custom clean-up actions on various symbol types, much like the purpose of %destructor. (Without it, you might force the user to conform to some predefined interface.) I hope this isn't considered "hardcore." :) (Boost.Spirit is closer to hardcore, IMO.) I also strongly agree for an std::istream/ostream interface. I'd like to parse strings in the program without having to go through a FILE* buffer. The C++ parser should be stream-agnostic (fstreams work as well as stringstreams). > I'm not strong with portability issues, so I'll rely on others to figure > that part out. Happy to advise on portability. :) I've spent too much time on C++ yacc-robatics and ridiculous backwards compatibility. Side note, I'm also wondering if support for other output languages would be made easier by exposing some sort of meta-skeleton, whereby the pieces of the generated parser can be expressed as a framework and pieced together using per-language templates. The common work of computing state transition tables can be done in a front-end, like the old y.tab.cc. Each "back-end" could even be compiled as a library or plug-in, making support for new languages modular. (parser generator generator generator, anyone?) Fang David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison