Hi Adrian, Thanks for the feedback.
> Le 3 juil. 2019 à 14:08, Adrian Vogelsgesang <[email protected]> a > écrit : > > Hi Akim, > > collecting statistics about a parse sounds like a great idea to me > and I am looking forward to it. > Thanks for the time and effort you spent on this! :) Well, on this particular feature, I was driven by own needs :) But thank you. > For my projects, I don’t care which exact option is pursued since > I never use `yydebug` in commited code. I only add debug > code temporarily, fix the bug, and then remove the debug code > again before commiting anything to master. Ok. Which means you commit the generated files? > I don’t think anyone should have a dependency in production > code on `yydebug` behavior. Well, Bison, when installed, does keep the parser traces on (and you can trigger them with --trace=parse). But you are right: this is debatable. I should probably stop doing this in the generated tarball. It's ok for the git repo, but maybe the generate tarballs should not have it enabled by default. > Hence, I guess breaking the > POSIX standard here would be fine. > Still, I share your concerns about breaking standards. > > Hence, I would be in favour of variant 2 or 3. Thanks for the feedback! > One question regarding variant 3a: > What would be the outcome of the combination >> %define parse.trace false >> %define parse.stats true I don't like 3a, I prefer 3b :) But in the case you quote, I would probably make it an error: you cannot set parse.stats if parse.trace is not enabled. But then again, I mentioned 3a only to explain the commit. I should have emphasized that it's a bad solution: enhancing parse.trace is better imho.
