Le 1 avr. 07 à 06:46, Joel E. Denny a écrit :
On Fri, 30 Mar 2007, Akim Demaille wrote:
- first, design a true AST for Bison
something to represent the grammar we read. We have more or less
something like this in Bison, but much work is done on it, it's not
"faithful" to the entry, it's already heavily modified.
Once this AST done, then be ready to process it for real, applying
all the transformations we want (elimination of useless things,
elimination of symbolic names, elimination of mid-rule actions,
fuse
the %unions, run semantic checks etc.).
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.
IMO there is actually more value to get from this rewrite than
from %import itself: the latter is very reachable from the former.
And a clean AST will considerably ease many other improvements.
Not to mention that some of the bugs we hit would never have
existed in the first place.
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.
I wholeheartedly agree. Moreover, I guess harder constructs are
less portable anyway. What I mean when I say C++ for Bison is
basically classes (with private parts), iostreams, and structures such
as lists and vectors.
I'm not strong with portability issues, so I'll rely on others to
figure
that part out.
If Paul is on our side and the project is accepted, let ask
rms again.
_______________________________________________
[email protected] http://lists.gnu.org/mailman/listinfo/help-bison
