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

[Akim Demaille]

Le 10 avr. 09 à 20:59, Joel E. Denny a écrit :

Hi Joel,

> > %printer <int> { foo_int($$); }
> > %printer <string> { foo_string($$); }
> >
> > gives a yy_print_ that looks like
> >
> > parser::yy_print_ (const symbol_type& s)
> > {
> >  switch (s.type)
> >  case INT:     foo_int(s.value.as<int>());       break;
> >  case STRING:  foo_string(s.value.as<string>()); break;
> > }
>
> 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.  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.

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.

> In that case, I think it makes sense to consider something like a  
> $stream
> or %stream symbol.  It's probably not good to collide with the modulo
> operator, so probably not %stream.

Right.

> $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 $ 
{}.  Maybe getting out of the symbol charset?

%printer { $[<<] << $$; }

Not too good either :(

If we don't expect to have other cases, maybe we can leave with

%printer { $@ << $$; }

which kind of makes sense in Make parlance.