[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
C++ parsers
From: |
Hans Aberg |
Subject: |
C++ parsers |
Date: |
Wed, 11 Jun 2003 00:53:21 +0200 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- C++ parsers,
Hans Aberg <=