[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Parser base class (lalr1)
From: |
Akim Demaille |
Subject: |
Re: Parser base class (lalr1) |
Date: |
Thu, 29 Sep 2005 11:21:21 +0200 |
User-agent: |
Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) |
>>> "Jan" == Jan Nabbefeld <address@hidden> writes:
> A piece of the parser file:
> -8<-----
> /* ... */
> cd_list: /* empty */ {$$=0;}
>> cd_list cd { $$ = NRec(token, _CD_LIST, $1, $2, _CD); }
> ;
> cd: opt_final class_definition ';'
> { $$ = NLift(token, _CD, $1, $2, _OPT_FINAL, _CLASS_DEFINITION); }
> ;
> opt_final: /* empty */ {$$=0;}
>> FINAL { $$=NNew(token); $$->type=FINAL; }
> ;
> /* ... */
> -8<-----
> I would love to have NNew(), NLift() and NRec() as parser methods (for
> building AST).
:( Well, that's pretty much not elegant. I'm also using lalr1.cc to
build an ast, but it looks like this:
exp.nonlvalue:
"nil"
{ $$ = new ast::NilExp (@$); }
| "(" exps.0.2 ")"
{ $$ = new ast::SeqExp (@$, $2); }
| "(" error ")"
{ $$ = new ast::SeqExp (@$, new ast::exps_type); }
| lvalue ":=" exp
{ $$ = new ast::AssignExp (@$, $1, $3); }
| "if" exp "then" exp
{ $$ = new ast::IfExp (@$, $2, $4); }
| "if" exp "then" exp "else" exp
{ $$ = new ast::IfExp (@$, $2, $4, $6); }
etc. etc.
A simple `using namespace ast' removes the ast:: if needed.
> Also the initial AST node would be a usefull class attribute in
> parser.
Sorry, I don't quite understand what you mean with `the initial ast
node'.
> Unfortunately I'm bound by the BNF rules shown above. So changes
> can only be made on the surrounding code.
> Parent class of generated yy::parser:
> -8<-----
> class parserBase:
> {
> public:
> parserBase(const Param& p) :
> lexer (new FlexLexer ()),
> token (new TokenType ()),
> ast (0)
> {}
> tree * ast;
> tree * NNew(tokenType *);
> ...
> }
> -8<-----
> This works well with Bison <= 1.875e (OK, skeleton changes between the
> 1.875x releases broke the code again but it worked in general). I know
> lalr1.cc skeleton is experimantal and not supported so I don't complain
> about that. Would be nice to have the possibility again without
> customize the skeleton.
I have not understood what mandates that these NNew etc. be members of
the parser. They can be non member functions used by the parser, no?
Have a look at examples/calc++ in the Bison distro: that's what I have
in mind for the "right" use.