Re: [PATCH] Factor %FLAG at scan level.

[Akim Demaille]

Le 15 avr. 09 à 03:37, Joel E. Denny a écrit :

> Hi Akim,

Hi Joel!

> On Mon, 13 Apr 2009, Akim Demaille wrote:
>
> > Le 10 avr. 09  20:59, Joel E. Denny a crit :
>
> > > So you have decided for sure not to pass %parse-params to %printer.
> > > That's the point where we diverged.
> >
> > No it is not :)  In the case of C++ the parse-param are actually  
> > attributes
> > of the class, so I don't have to pass them to the printer, they  
> > just *are*
> > available.
>
> But not in operator<< for symbol_type, right?  I just noticed your  
> TODO
> entry on this topic, and it says that the symbol_type is not bound  
> to a
> particular parser, so I assume that means the symbol_type operator<<
> cannot invoke %printer's.  This point is what I meant to be talking  
> about,
> and it's why I pointed out that the user will instead have to write
> %printer to invoke symbol_type operator<< if he wants to maximize code
> reuse.

<rms mode>We are miscommunicating here.</rms mode>

There must be some loop somewhere in our discussion, and I'm not sure  
that we understand each other.

There are two different things we are talking about (or so I  
believe).  (1) the introduction of an operator<< for symbol_type and  
(2) its use in %printer.

(1) Today there is no operator<< for symbol_type, and the whole  
discussion starts from the fact that I am very much in favor of  
providing it, instead of yy::parser::yy_print_(symbol_type&).  It just  
much more natural in C++.  *But* the problem if I depart from the  
current interface (yy::parser::yy_print_(symbol_type&)) is that the  
user can no longer be given access to the %parse-params, it just does  
not match the signature of the operator<<: %parse-params are not  
available in the operator<< so they can no longer be used in the body  
of the %printer.  I am convinced this is not a problem and that it is  
weird to need a %parse-param in the %printer, but still, that's a  
change of API.  But given that I discovered that %printer was not  
documented, I can live with that change more easily than I thought  
some time ago.

There is also the other, less dramatic, issue: how to pass the ostream  
to the %printer.  We will always find something, including defining  
debug_stream() as a macro or new directives.

Everything we said here is just the same for the symbol_type  
destructor, which should replace  
yy::parser::yy_destroy(symbol_type&).  In the case of the destructor I  
can see more reasons to be willing to use the %parse-param, say for  
some memory pool or whatever, I don't know.  Maybe we should let the  
user decide between printer and destructor that are yy::parser  
members, or "natural" features of symbol_type.

(2)  yy::parser::yy_print_(symbol_type&) is a big switch/case that  
bounces to the various %printer implementation, so when we replace  
yy::parser::yy_print_(symbol_type&) by an operator<<(ostream&,  
symbol_type&), of course that very operator cannot be used in the  
various %printer.  Just like the various %destructors will generate  
the body of the symbol_type destructor, so the formers cannot use the  
latter.  So really, I don't understand what you mean in "the user will  
instead have to write %printer to invoke symbol_type operator<< if he  
wants to maximize code reuse".

Writing the set of %printers *is* defining how a symbol_type is to be  
printed, whatever the printing routine is named.

A symbol_type is a variant/tagged union.  To print the symbol_type, we  
need to look at its tag to know what is its genuine type, and then to  
dispatch to the actual type-dependent implementation.



Am I making more sense?  There must be something I have not  
understood, but I don't understand what :(