[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: %merge confusion
From: |
Akim Demaille |
Subject: |
Re: %merge confusion |
Date: |
Mon, 28 Dec 2020 08:01:44 +0100 |
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!
Re: %merge confusion, Akim Demaille, 2020/12/27