Hi Anatol, On Tue, Feb 10, 2015 at 3:35 PM, Anatol Belski <anatol....@belski.net> wrote: > > Maybe it'd be worth it to move one step after another, see what features > can be implemented and how do they improve? Maybe they'll be so crucial to > even make a special case that one can say - yeah, don't care about > flexibility? Not that one would restrict something without having the bare > reason in the hand. > > I have been thinking about it and think that you have got a point. Let's wait when the implementation is ready and then we can make a decision if it's worthy breaking the flexibility. I have got few other things on my list before that so it will probably take some time to do the changes and test it...
I would like to push the the bison tab files shortly as the majority of people in this thread (including me) are for having them in the repo. The only thing that I would like is to have a specific version in the repo to prevent big diffs for small changes in the source files. For now I would like to have there re2c 0.13.6 (thanks for regenerating it back ;) ) and bison 2.7.1 gen files. I will update Readme at some point as well and add there that info. I think that that all compat are types fixes are sort of done so it would be probably best to do PR for all json changes as it has lots of advantages (I'm sure that you all know them so I won't name them... :) ) I won't be adding the config.m4 stuff that is in the PR though. I realized that it would a bit of hack just for json which probably not good. However I still like the idea of removing re2c and bison dependency for all users that don't need to change parsers or scanners. That will require more changes to the build and probably RFC so it's a bit off-topic. I'll see if I get time to propose something like that in the future. Cheers Jakub