[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: Wed, 15 Apr 2009 10:26:00 +0200

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*

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

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

reply via email to

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