C++ parsers

[Hans Aberg]

Was: GLR parsers and locations
At 14:52 -0700 2003/06/10, Paul Hilfinger wrote:
>> You mean nontermination in GRL C++ parsers here, right?
>
>No; I was referring to the "Simple LALR1 C++ Calculator" tests in
>calc.at, which are not GLR.  It's just that I always do a "make check"
>before I submit anything, so I see all the regressions, GLR and
>otherwise.  As far as I know, there are no GLR regressions in the
>suite at the moment.
>
>By the way, I think that the lalr1.cc is probably relatively easy to
>fix.  I think it's just a matter of inserting "FOO.pop (len_);" calls
>to pop the RHS off all the stacks upon execution of YYERROR.  However,
>I didn't have the leisure to go poking around in lalr1.cc to see what
>else might need adjusting as a result.

I am using my own C++ skeleton file, which I combine with some Bison
tweaking: Under C++, and also when integrating with Flex classes, I want to
be able to put code in several places. The tweak is merely to not tie the
two .y file initial %{ ... }% segments (the pre-prologue and the
%post-prologue) to the presence of a %union. (Instead of %union, I use a
polymorphic class hierarchy with a reference count, so I do not need
%union, and unions do not work with C++ classes having nontrivial
constructors.)

Ideally, I would want a Bison command
  %code <identifier> { <code> }
which would create an M4 macro with a name derived from <identifier>,
expanding to <code>. Then one could use that to put code in several
different places. Probably easy to implement, but I can't do that right now.

  Hans Aberg