[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Akim Demaille
Subject: Re: [PATCH] Factor %FLAG at scan level.
Date: Mon, 13 Apr 2009 23:43:18 +0200

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(<int>());       break;
 case STRING:  foo_string(<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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]