Re: %merge confusion

[Akim Demaille]

Jot,

> Le 27 déc. 2020 à 22:31, Jot Dot <jotdot@shaw.ca> a écrit :
> 
> 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

Ok, this should have worked.  This is a limitation in the current releases.
I can prepare a tarball with a fix in the near future for this if you're
interested.

>> 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.

You are not doing anything wrong, Bison is.  Support for api.value.type
union missed the case of the mergers.


>> +       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?

Just read carefully my email, everything is in it.

> 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.

Note also that I wrote (and you quoted) "the names have changed since then".
But the logic is the same.  That's in src/output.c.


> 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.

The code works when api.value.type union is not used, for instance when you
use %union.


>> 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..

The nature of the data (POD or object) is irrelevant here.  The question is
really that currently there are two signatures for mergers:

untyped: (YYSTYPE, YYSTYPE) -> YYSTYPE
typed:   (YYSTYPE, YYSTYPE) -> gen::index_t

The typed signature has two problems: (a) it is badly implemented in the
case of api.value.type=union, and (b) I don't understand why the typed
alternative is not

(gen::index_t, gen::index_t) -> gen::index_t

You did not provide the implementation of your merger, I'd like to see it.


Cheers!