Re: Parser base class (lalr1)

[Hans Aberg]

On 28 Sep 2005, at 14:37, Jan Nabbefeld wrote:

> >  > about the possibelity off defining a base class for the generated
> >  > yy::parser in lalr1 skeleton. Further I noticed that this was
> >  > removed from the lalr1 skeleton on December 2004.
> > That is right, it seemed to cause more problems than provide
> > solutions.  Do you have a concrete example where this would be  
> > useful?
> > Would you also want to derive from it?
>
> 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). Also the initial AST node would be a usefull  
> class attribute in parser. Unfortunately I'm bound by the BNF rules  
> shown above. So changes can only be made on the surrounding code.

I use a C++ polymorphic hierarchy, with a reference count at the  
base, in order to avoid unnecessary copying.

This approach has also the advantage of making use of C++ cleanup

The code above then becomes:

cd_list: /* empty */ {$$=0;}
    | cd_list cd { $$ = new NRec(token, _CD_LIST, $1, $2, _CD); }
;

cd: opt_final class_definition ';'
  { $$ = new NLift(token, _CD, $1, $2, _OPT_FINAL,  
_CLASS_DEFINITION); }
;

opt_final: /* empty */  {$$=0;}
    | FINAL { $$ = new NNew(token); $$->type=FINAL; }
;

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

If you use only a pointer here (tree *), you must do cleuo by hand  
plus using %destructor during error recovery.

I have found, though that in addition to the semantic values that the  
parser builds, I need alos to make use of token type as well its  
name. Possibly, this should be put into a special area in the parser  
stack, even though it is easy to put it into the semantic stack.

> 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.

When Akim has finished the writing of %define, customizing will be easy.