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

[Joel E. Denny]

Hi Akim,

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.

> And I wish they were not, that's the whole problem.  Likewise
> for the destructor.  I would like them not to be member of the parser class.

It's also inconsistent with the way we handled %parse-params' and yypstate 
in the push code in yacc.c.  I wasn't aware of the inconsistency at that 
time.

(It just struck me that yypstate is not a good name.  I was thinking of it 
as the full run-time state of the parser, but it sounds like it's a parser 
state from the parser tables.)

> Maybe I'm overrating this and no-one is actually depending on the parser class
> features in the %printers and %destructors *in C++*, I don't know.  I fail to 
> see good reasons to do so in C++/Java.   

I don't know either.  If the backward-compatibility issues get too much in 
the way, you could always start with a new skeleton name.  With IELR(1) in 
place, the lalr1 file name becomes a misnomer anyway.  Of course, 
maintaining two versions would be a chore.

> > $stream or $[stream] looks like a
> > value name.  Maybe we need to develop a general syntax for this sort of
> > thing.  I think ${stream} looks like a macro, which is sort of the right
> > sense.  I wish we had more than $ and @ available.
> 
> I'm not too happy with having to make a difference between $[] and ${}.

I understand.

> Maybe
> getting out of the symbol charset?
> 
> %printer { $[<<] << $$; }
> 
> Not too good either :(

It looks like it references the value of a strange grammar symbol.

> If we don't expect to have other cases, maybe we can leave with
> 
> %printer { $@ << $$; }
> 
> which kind of makes sense in Make parlance.

I don't know.  It's so close to @$, and I have a feeling this won't be the 
last special symbol we need.

Maybe we should come up with a general notation that, like %define and 
%code, each skeleton could employ in a custom manner.  That is, 
scan-code.l would convert the ${NAME} notation to some sort of 
b4_action_token(NAME) macro that skeletons could expand in whatever way 
they need.  We'd implement some generic mechanism to complain if a 
skeleton doesn't provide an expansion.

To be safe in C-like languages, I guess the notation has to start with $ 
or @.  If ${...} and $(...) are not distinct enough from $[...], then 
maybe we need another character after $.  Something like $&stream, 
$*stream, $?stream?, $:stream:, etc.