Re: %merge confusion

[Akim Demaille]

Hi all,

> Le 27 déc. 2020 à 17:03, Akim Demaille <akim@lrde.epita.fr> a écrit :
> 
> Your problem follows from the fact that there is support for "typed" mergers.
> 
> FWIW, I was unaware of this feature (the fact that the merge functions are 
> "typed").  This is undocumented, yet dates back from the initial introduction 
> of GLR in Bison:
> 
> commit 676385e29c4aedfc05d20daf1ef20cd4ccc84856
> Author: Paul Hilfinger <Hilfinger@CS.Berkeley.EDU>
> Date:   Fri Jun 28 02:26:44 2002 +0000
> 
>    Initial check-in introducing experimental GLR parsing.  See entry in
>    ChangeLog dated 2002-06-27 from Paul Hilfinger for details.
> 
> +void
> +merger_output (FILE *out)
> +{
> +  int n;
> +  merger_list* p;
> +
> +  fputs ("m4_define([b4_mergers], \n[[", out);
> +  for (n = 1, p = merge_functions; p != NULL; n += 1, p = p->next) 
> +    {
> +      if (p->type[0] == '\0') 
> +       fprintf (out, "  case %d: yyval = %s (*yy0, *yy1); break;\n",
> +                n, p->name);
> +      else
> +       fprintf (out, "  case %d: yyval.%s = %s (*yy0, *yy1); break;\n",
> +                n, p->type, p->name);
> +    }
> +  fputs ("]])\n\n", out);
> +}

This closes the loop and documents typed mergers.

Cheers!

commit ebc845e39f4ec161a1492e328b3339c53379d53d
Author: Akim Demaille <akim.demaille@gmail.com>
Date:   Wed Aug 4 09:06:56 2021 +0200

    doc: glr: document typed mergers
    
    See <https://lists.gnu.org/r/help-bison/2020-12/msg00016.html>.
    
    * doc/bison.texi (Merging GLR Parses): document typed mergers.
    And avoid #define YYSTYPE.

diff --git a/TODO b/TODO
index 52c595ddd..2e66eeec5 100644
--- a/TODO
+++ b/TODO
@@ -28,15 +28,6 @@ the out-of-range new values, we need something like doubling 
the size.
 ** glr
 There is no test with "Parse on stack %ld rejected by rule %d" in it.
 
-** %merge
-Tests with typed %merge: 716 717 718 740 741 742 746 747 748
-
-716: Duplicate representation of merged trees: glr.c FAILED 
(glr-regression.at:517)
-740: Leaked semantic values if user action cuts parse: glr.c FAILED 
(glr-regression.at:1230)
-746: Incorrect lookahead during nondeterministic GLR: glr.c FAILED 
(glr-regression.at:1610)
-
-Document typed merges.
-
 ** yyrline etc.
 Clarify that rule numbers in the skeletons are 1-based.
 
diff --git a/doc/bison.texi b/doc/bison.texi
index e2cd1525d..f73cc8194 100644
--- a/doc/bison.texi
+++ b/doc/bison.texi
@@ -1167,11 +1167,12 @@ Let's consider an example, vastly simplified from a C++ 
grammar.
 @example
 %@{
   #include <stdio.h>
-  #define YYSTYPE char const *
   int yylex (void);
   void yyerror (char const *);
 %@}
 
+%define api.value.type @{char const *@}
+
 %token TYPENAME ID
 
 %right '='
@@ -1302,7 +1303,6 @@ in the C declarations at the beginning of the file:
 
 @example
 %@{
-  #define YYSTYPE char const *
   static YYSTYPE stmtMerge (YYSTYPE x0, YYSTYPE x1);
 %@}
 @end example
@@ -1321,6 +1321,48 @@ productions that participate in any particular merge 
have identical
 and the parser will report an error during any parse that results in
 the offending merge.
 
+@sp 1
+
+The signature of the merger depends on the type of the symbol.  In the
+previous example, the merged-to symbol (@code{stmt}) does not have a
+specific type, and the merger is
+
+@example
+YYSTYPE stmtMerge (YYSTYPE x0, YYSTYPE x1);
+@end example
+
+@noindent
+However, if @code{stmt} had a declared type, e.g.,
+
+@example
+%type <Node *> stmt;
+@end example
+
+@noindent
+or
+
+@example
+@group
+%union @{
+  Node *node;
+  ...
+@};
+@end group
+%type <node> stmt;
+@end example
+
+@noindent
+then the prototype of the merger must be:
+
+@example
+Node *stmtMerge (YYSTYPE x0, YYSTYPE x1);
+@end example
+
+@noindent
+(This signature might be a mistake originally, and maybe it should have been
+@samp{Node *stmtMerge (Node *x0, Node *x1)}.  If you have an opinion about
+it, please let us know.)
+
 @node GLR Semantic Actions
 @subsection GLR Semantic Actions