Re[2]: Support emplace with multiple arguments

[Askar Safin]

>Please, have a look at the thread "Dynamic token kinds", in
>particular this message (and its follow-up):
>
>http://lists.gnu.org/archive/html/bug-bison/2018-12/msg00052.html
>
>It might address your concern.

Hi. I tried this patch and I want to share my experience.

But first of all I want to say this: I like this patch, but I will not use its 
functionality anyway (reasons are near end of this message).

So, I tried to get this patch. Your message ( 
http://lists.gnu.org/archive/html/bug-bison/2018-12/msg00052.html ) says that 
commit id is 1f86c28ea2ff69f68a569568ad6890dee3ac9684. So I tried to find this 
commit at http://git.savannah.gnu.org/cgit/bison.git and I was unable to do 
that. Also I cloned git://git.savannah.gnu.org/bison.git and also was unable to 
find there that commit. So, here comes

Problem #1. The commit is not present at git://git.savannah.gnu.org/bison.git 
(as on 2018-12-21 10:20 UTC).

Then I tried just to copy-paste patch from message. Here I want to note that I 
am not subscribed to bison-bugs, so I don't have this message in my mailbox. So 
I had to copy-paste in from 
http://lists.gnu.org/archive/html/bug-bison/2018-12/msg00052.html . But this 
did not work, because the patch is polluted with strings "address@hidden". 
(Also I want to insert a note for those who read this message at 
http://lists.gnu.org/archive/html/bug-bison: I actually mean address@hidden 
here, i. e. word "address", then at sign and then word "hidden"). And also its 
lines are broken in random places. So,

Problem #2. Copy-pasting from http://lists.gnu.org/archive/html/bug-bison 
doesn't work, too, because messages are polluted with "address@hidden" 
("address", then "at", then "hidden") and lines are broken in random places.

Then I noticed a link "download the archives in mbox format" at the 
http://lists.gnu.org/archive/html/bug-bison . So I downloaded mbox for 
December. And manually extracted the patch. This was not easy, because I had to 
manually convert various =20, =3D, etc. But finally I got working patch.

So, I understand why people didn't try your patch. They probably simply was 
unable to download it.

Okey, so I was able to apply patch. And I wrote the following code: (see 
attachments). And it works. So, yes, I like the patch.

But I will not use this functionality anyway. Here is why.

I use Bison very often. And every time I use it I just need to generate some 
AST. I am boring to write this repetitive Bison files, which generate AST. So I 
am now working on Haskell library, which will generate such Bison files. Work 
is nearly complete. When I will be ready, I show the project on this list. I 
hope I will be done in several days.

I decided to make my generated Bison files as general as possible. So, I use 
%skeleton "glr.cc". Because it is quite possible that some day I will need 
parser to some non-LALR1 language. But this means that:
* I cannot use %define api.value.type variant
* I have to pass around std::variant, std::string etc using raw pointers
* And thus I cannot use %define api.token.constructor
* And also I cannot use %define api.value.automove

Even if you add, say, "%define api.value.type variant" to GLR parsers, this 
will not change anything for me. Because when I finish my project, I probably 
will not write Bison files anymore by hand. So Bison capabilities simply will 
become irrelevant for me.

==
Askar Safin
http://vk.com/safinaskar

parser.ypp
Description: Binary data

scanner.lpp
Description: Binary data