Re: %merge confusion

[Akim Demaille]

Hi Jot,

> Le 1 janv. 2021 à 23:32, Jot Dot <jotdot@shaw.ca> a écrit :
> 
> But, in my defence:
>        *******************************************************
>        *** That wasn't what I was asking for all this time ***
>        *******************************************************

Ok :)


>> 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 ....
> 
> I've asked many times in different ways what was I was doing that makes
> this a "typed merger" and how I could change it so I do not use this "typed 
> merger"
> signature and just use "untyped" merges.

I also already have answered to this question: you have used
api.value.type=union, or %union, etc.  Anything that specifies
the type *per symbol* will use typed merger.  The only exception
is

%define api.value.type {Foo}

which declares "*all* my symbols have type Foo".  It's equivalent
to "#define YYSTYPE Foo" in C.  Then it is untyped, in the sense
that symbols have no specific type, they are all the same, including
the symbols that actually have no value (say punctuation such as ';').

> So: Let's hit "reset" w/rt this topic and let me see if I am correctly
> summarising everything:
> 1) api.value.type variant is being worked on. Don't use this path yet.

I'm happy to report that it started to work yesterday.

> 2) api.value.type union is what was broken, not "typed mergers"

In 3.7.4.  It is fixed in the current development branch.  I
can provide a tarball on demand.

> 3) %union works

Yes.

> 4) "typed mergers" work but the merge prototype changes.

Yes.

> 5) The "untyped merger" is when I don't use %token and %type but that is
>   not applicable in my usage case so I must use "typed mergers"
> 
> So, using 3) and 4) *properly*, I should have no issues.

With 3.7.4, yes.  With the current master, 2 is safe.  1 works,
but is probably still a bit unstable.


I'll answer about the other topic later.

Cheers!