Hi Askar, > Le 21 déc. 2018 à 13:34, Askar Safin <[email protected]> a écrit : > > Hi. I tried this patch and I want to share my experience.
> 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. Sorry I was unclear. I wrote I have a draft for it in my repo, as "make-symbol". which refers to my GitHub repo. I'm not particularly happy to work with GitHub, but I did this so that I can have some CI to check Bison. And several users have already forked it. It can be convenient. https://github.com/akimd/bison/tree/make-symbol > So, I understand why people didn't try your patch. They probably simply was > unable to download it. I also asked for comments and opinions. That's the idea of peer-reviewing lists such as bison-patches. I much prefer educated answers from people who tried it, like you did, but opinions are already useful feedback. > 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. So I don't get comments about the patch itself from you either :( > 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 Yes, proper support for variant in glr.cc would be wonderful. Currently it's more a kludge than a proper skeleton written from scratch. Thanks for your answer anyway. Cheers.
