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

[Akim Demaille]

Le 10 avr. 09 à 16:36, Joel E. Denny a écrit :

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

I dislike that values and types leave in the same namespace in C++, so  
I usually use CamlCase names for my classes, and foo_type for my  
typedefs.  I think this is clearer.  square could just as well be an  
instance of Square.

That's what I did for parser::location_type, parser::value_type and so  
forth.

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

That's really simple.  With pseudo-code to be shorter:


%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;
}