Re: %merge confusion

[Akim Demaille]

Hi Jot,

> Le 28 déc. 2020 à 10:09, Jot Dot <jotdot@shaw.ca> a écrit :
> 
> I'm not trying to irritate you with all of this.

I'm sure you are not.


> Alright. I took out the 'api.value.type union' and put in:
> %union {
>  gen::index_t index;
>  merge_t merge;       // A struct to hold my merge info
> }
> 
> All my tokens are of the form: %token <index> tok1 tok2 tok3 ...
> All my rules are of the form: %type <index> rule1 rule2 rule3 ...
> 
> I get the same yyuserMerge as before. This time, it is using
> the new type of the rule that the merge is in (%type <index> rule)
> 
>  case 1: yy0->index = stmtMerge (*yy0, *yy1); break;

Which is good.  That is what is expected.


>> You did not provide the implementation of your merger, I'd like to see it.
> 
> The implementation is completely irrelevant.

Well, it is irrelevant for the piece of code above, granted.  But it
is to me who just discovered this feature and would like to know how
people are using it, so see if we should fix this typing issue of the
incoming arguments.

> It is as what the manual requested:
> static YYSTYPE stmtMerge (YYSTYPE x0, YYSTYPE x1);
> 
> Mine is the same, with no side-effects relating to bison.
> 
> static YYSTYPE stmtMerge(YYSTYPE x0, YYSTYPE x1)
> {
>    YYSTYPE st;
>    // I'm building a tree. I'm just marking the two nodes in the tree as 
> ambiguous.
>    st.merge.index = x0.merge.pResult->makeList(x0.merge.index, 
> x1.merge.index, node_t::list);
>    x0.merge.pResult->ambig(st.merge.index);
>    return st;
> }

I'm confused.  The code expects you to return an "index" here, and you
are inserting something into merge.  I don't understand what you are
doing.  You can't choose where to store the result, it _must_ be in
"index", not "merge".  The rest of the parsing will continue to use
"index" in the %union, not "merge".

You are merging two branches that computed an "index", and your merger
is expected to merge these two indexes into another "index".



> I am curious about one thing though. At first I wasn't fully sure what you
> meant by "typed mergers". Previously you stated:
> 
>> 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:
> 
> Looking at the manual's examples on the web page:
> https://www.gnu.org/software/bison/manual/html_node/Merging-GLR-Parses.html
> 
> The difference between those examples and what I am doing here is that
> I'm using '$$ = ' to assign values to rules and those examples don't.
> This means I must give the subrules a %type. The manual examples don't.
> Is this why it's a "typed merger"?  Which would mean the only glr examples 
> that
> will compile are ones that don't do a '$$ = ' which means my stuff won't work
> no matter what I do - and thus any additional effort to get this working
> is just wasting your time and mine?

No, the difference is that you have typed your symbols individually.
The examples in the documentation don't use %token <index>, %type <index>
etc.