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

[Joel E. Denny]

On Fri, 10 Apr 2009, Akim Demaille wrote:

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

Ah.  I agree completely.  I even use normal OO spellings like this in C 
where I employ an OO design.  Unfortunately, I feel compelled to flatten 
these spellings in my IELR implementation for GNU coding standards.  I 
wish I didn't have to.

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

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.