Re: %merge confusion

[Jot Dot]

BTW: I'm using: Bison 3.7.1

>> Assuming I have something simple like the following:
>> %token <some_type> IDENTIFIER
>> %type <some_type> subrule expr
> 
> Which means that you are probably using "api.value.type variant".  Which does

*Sigh*
That's why I was wondering what I was doing wrong.
I know I must use POD.
I should have also included in the lines above (which I use):
%define api.value.type union
I've even tried with and without: %skeleton "glr.cc"

> 
> Your problem follows from the fact that there is support for "typed" mergers.

I guess the question is "What am I doing wrong that is triggering this "typed"
merger feature?  I'd like to just use POD, since the underlying type for
my "gen::index_t" is simply an unsigned short.

> +       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);

> The else-clause (which is the one that introduces the yy0->TYPE (the names 
> have
> changed since then) which is broken in your case) is undocumented, but there
> are a few test cases in the test suite.

Ok. I'm using Bison 3.7.1  I'm assuming your pasted code is recent as well?
I see the output is "yylval = " but I am using the C++ variant which I believe
implies %pure and thus yylval is undefined. Note that in my pasted code, the
difference is is yy0 is both lhs and an arg to the user's merge call.

Are these few test cases enabled and working properly?
I mean, my code is trying to treat a type as a variable!
I can't see anything compiling at all when using this feature.

> I don't understand the design of this feature: why is it asymmetrical?  I 
> mean:
> the input arguments are "untyped" (they are YYSTYPE, i.e., the union of all 
> the
> types used in the grammar), while the output is the exact type of the current
> lhs.  I would have used the exact type in both cases.

I agree.  Especially in the case of POD.. that's why I mentioned that
*yy0 = stmtMerge...
looked better (I'm thinking of stack reductions and the args are the two 
topmost).
But that was a naive guess - that the merge, no matter what variations are
implemented, would probably be doing some same fundamental concept in that 
routine.
The only thing that makes sense (to me) is the user supplied routine returns a 
YYSTYPE
and that is stored inside some bigger struct but then now I am really guessing
and, since I don't know any internals, this guessing won't get me anywhere.

> I'd like to fix that, but I'm not sure how to do that in a backward compatible
> way.

I think, in my quest to convert my stuff to POD, I must have done something 
wrong and
there is an uncaught error in my stuff that is triggering this - and thus bison 
is
spitting out code that is not workable.
It's also my guess that the "typed merge" feature has been broken for quite 
some time.

In any case, I simply am trying to use POD data types and have no clue to what 
I am
doing to invoke this "typed" merge feature you mention.

Do you have any idea or am I dealing with bison in transition (re: glr) and
thus I need to wait?

Thanks for responding btw