Re: Fwd: Are Google summer of code 2006 ideas still available?

[David Fang]

> 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!)