[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Factor %FLAG at scan level.
From: |
Joel E. Denny |
Subject: |
Re: [PATCH] Factor %FLAG at scan level. |
Date: |
Fri, 10 Apr 2009 14:59:51 -0400 (EDT) |
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.
- [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/03
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/03
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/04
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/06
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/08
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/08
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/09
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/10
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/10
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/10
- Re: [PATCH] Factor %FLAG at scan level.,
Joel E. Denny <=
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/14
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/14
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/15
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/16
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/09
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/10
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/10
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/14
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/14
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/08