[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bison 3.0: enhancement request proposal
From: |
Akim Demaille |
Subject: |
Re: Bison 3.0: enhancement request proposal |
Date: |
Mon, 31 Dec 2018 08:26:36 +0100 |
Hi Francis,
> Le 30 août 2015 à 12:21, Francis ANDRE <address@hidden> a écrit :
>
> Hi
>
> I am using Bison for a grammar that brings conflicting names like the
> following use case:
>
> %token IDENTIFIER "IDENTIFIER" // the keyword IDENTIFIER
> %token identifier // the terminal identifier for
> lower case name
>
> Bison generates then
>
> #ifndef YYTOKENTYPE
> # define YYTOKENTYPE
> enum yytokentype
> {
> IDENTIFIER = 100,
> identifier = 101,
> ...
>
> fine... but I would like to use the name "identifier" in some parser C++ code
> and that's not possible because it is already used in the enum yytokentype.
> Thus I am proposing to add a directive to Bison for specifying the list of
> token as an C++ enum class type as
>
> % enum-class = "MyTokens";
>
> so that Bison would generate
>
> #ifndef YYTOKENTYPE
> # define YYTOKENTYPE
> enum class MyTokens
> {
> IDENTIFIER = 100,
> identifier = 101,
> ...
>
> and replace yytokentype by MyTokens everywhere. As such, the token would need
> to be qualified by MyTokens:: in the lexer and in semantic actions and that
> exactly what is needed to keep the name "identifier" used out of the parser's
> code.
>
> Regards
For the records, Bison does that with C++ parsers. Otherwise,
in C, you should have a look at %define api.token.prefix.
Cheers!
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Bison 3.0: enhancement request proposal,
Akim Demaille <=