[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: Fri, 10 Apr 2009 17:15:20 +0200

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

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(<int>());       break;
  case STRING:  foo_string(<string>()); break;

reply via email to

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