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

[Joel E. Denny]

Hi Akim,

On Thu, 9 Apr 2009, Akim Demaille wrote:

> > I'm not suggesting we change that.  I'm just suggesting that %printer also
> > have access to the symbol_type object as well.  Otherwise, the user will
> > have to put the parts together by constructing his own temporary
> > symbol_type object in order to invoke operator<< from within %printer.
> 
> I'm sorry, I don't understand here.  Sure, we can provided access to it, but
> to what end? operator<< of a symbol_type bounces to the various %printer
> implementations, so these should not bounce back to it.

I think this is the main point of my misunderstanding.  I thought you had 
decided operator<< could not invoke %printer because operator<< did not 
have access to the parse params required by %printer.  I suggested that 
%printer would instead invoke operator<<.  It's the reverse.  It's not a 
recursion.

However, I think maybe I need to study your C++ skeletons more before I 
can discuss this issue intelligently.

> > By the way, why "symbol_type"?  Why not just "symbol"?  Isn't the symbol
> > type just one field of the triple?  Maybe I'm misunderstanding something
> > fundamental.
> 
> What I call a symbol (implemented as the type symbol_type)

Hmm.  If I wanted a class for squares and circles, I would call them 
square and circle not square_type and circle_type.  Otherwise, every class 
ends with _type, which seems redundant.  Maybe I'm misunderstanding the 
reason for _type.

> One issue with the current interface for %printer is also that I encourage
> users to output on debug_stream().  So of course we could

Before I can think about this issue, I really need to understand the 
relationship between operator<< and %printer.

Sorry for the confusion.