bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RIP: c++: merge symbol_type and token


From: Frank Heckenbach
Subject: Re: RIP: c++: merge symbol_type and token
Date: Sun, 23 Dec 2018 21:34:25 +0100

Akim Demaille wrote:

> > I see. So struct token only exists to put the yytokentype values in
> > their own namespace to avoid those clashes. An enum class would do
> > the same trick (and provide for stricter type-checking), but of
> > course requires C++11.
> 
> Actually, it would not help either.  We don't need enum class,
> embedding the enum in a class gives exactly the same scoping
> behavior.  So if I were to define
> 
> struct token
> {
>   enum class token_type { foo, bar };
> };
> 
> the users would have to write yy::parser::token::token_type::foo,
> which is a breaking change, and is too long imho.  The only
> real alternative would be to rename all the routines of `token`
> as yy_ something.  Including `token` itself.  Then provide a type
> alias for backward compatibility.  That should work.

I meant just "enum class token { foo, bar };", replacing the
namespace provided by the struct by the one provided by the enum
class, not adding another layer, i.e. not merging it with
symbol_type, just get rid of a dummy struct. Sorry if I wasn't
clear. But of course, not now, but possibly sometime in the future.

> > Would it help if Bison (internally) generates enum values for the
> > chars used, such as "TOK_46 = '.'" (with some non-conflicting
> > prefix), so token_type would cover all valid values and could be
> > used as the parameter type? (This might also be required for the
> > stricter type-checking of an enum class.)
> 
> Yes, we can do that.  However, I don't think there's a real
> value for it: the user cannot guess the name, she would have
> to read the code, and it's of course fragile, that number can
> change easily.
>
> The only alternative I see would be to teach Bison the name
> of these characters: '+' => PLUS, etc.  That would allow to
> generate not only a better enum, but also the token constructors
> (make_PLUS).

That might be overkill. The new safe constructor should be fine
(especially as such tokens are usually untyped, anyway), and those
who want names can declare the tokens. So forget my suggestion, I
think we can leave it as it is now.

Regards,
Frank



reply via email to

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