[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bison 3.3.1 released [stable]
From: |
Akim Demaille |
Subject: |
Re: Bison 3.3.1 released [stable] |
Date: |
Sun, 3 Feb 2019 10:20:38 +0100 |
Hi Frank,
> Le 29 janv. 2019 à 21:30, Frank Heckenbach <address@hidden> a écrit :
>
> Bison 3.3.1 works for me without problems or warnings.
Great!
> My only suggestion is about the wording in this announcement
> (and also in the manual):
>
>> *** ? C++: Actual token constructors
>>
>> For instance with these declarations
>>
>> %token ':'
>> <std::string> ID
>> <int> INT;
>>
>> you may use these constructors:
>>
>> symbol_type (int token, const std::string&);
>> symbol_type (int token, const int&);
>> symbol_type (int token);
>>
>> which should be used in a Flex-scanner as follows.
>>
>> %%
>> [a-z]+ return yy::parser::symbol_type (ID, yytext);
>> [0-9]+ return yy::parser::symbol_type (INT, text_to_int (yytext);
>> ":" return yy::parser::symbol_type (':');
>> <<EOF>> return yy::parser::symbol_type (0);
>
> This might be read as suggesting to use the new constructors in
> cases like these, which was probably not your intention; when the
> token kind is known at compile time, such as here, I think the named
> token constructors (make_FOO) are still pereferable. The new
> constructors are needed when the kind is only determined at runtime,
> such as in a hypothetical example like this:
>
> [a-z]+ if (auto i = lookup_keyword (yytext))
> return yy::parser::symbol_type (i);
> return yy::parser::make_ID (yytext);
You are right, this is much better. I'll install this:
commit e72b66a3c3497ca458da862701d670a14f864775
Author: Akim Demaille <address@hidden>
Date: Sun Feb 3 09:32:12 2019 +0100
NEWS: named constructors are preferable to symbol_type ctors
Reported by Frank Heckenbach.
http://lists.gnu.org/archive/html/bug-bison/2019-01/msg00043.html
diff --git a/NEWS b/NEWS
index f5475861..9880d609 100644
--- a/NEWS
+++ b/NEWS
@@ -223,17 +223,18 @@ GNU Bison NEWS
symbol_type (int token, const int&);
symbol_type (int token);
- which should be used in a Flex-scanner as follows.
-
- %%
- [a-z]+ return yy::parser::symbol_type (ID, yytext);
- [0-9]+ return yy::parser::symbol_type (INT, text_to_int (yytext);
- ":" return yy::parser::symbol_type (’:’);
- <<EOF>> return yy::parser::symbol_type (0);
-
Correct matching between token types and value types is checked via
- 'assert'. For instance, 'symbol_type (ID, 42)' would abort (while
- 'make_ID (42)' would not even compile).
+ 'assert'; for instance, 'symbol_type (ID, 42)' would abort. Named
+ constructors are preferable, as they offer better type safety (for
+ instance 'make_ID (42)' would not even compile), but symbol_type
+ constructors may help when token types are discovered at run-time, e.g.,
+
+ [a-z]+ {
+ if (auto i = lookup_keyword (yytext))
+ return yy::parser::symbol_type (i);
+ else
+ return yy::parser::make_ID (yytext);
+ }
*** C++: Variadic emplace
@@ -3486,7 +3487,7 @@ along with this program. If not, see
<http://www.gnu.org/licenses/>.
LocalWords: Heimbigner AST src ast Makefile srcdir MinGW xxlex XXSTYPE
LocalWords: XXLTYPE strictfp IDEs ffixit fdiagnostics parseable fixits
LocalWords: Wdeprecated yytext Variadic variadic yyrhs yyphrs RCS README
- LocalWords: noexcept constexpr ispell american
+ LocalWords: noexcept constexpr ispell american deprecations
Local Variables:
ispell-dictionary: "american"
- Re: Bison 3.3.1 released [stable],
Akim Demaille <=