>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
