Re: Bison 3.3.1 released [stable]

[Akim Demaille]

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"