-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
linting old coding style #305
Comments
That's an interesting idea. I've just looked at the code a little bit, but it could be useful if the user also has access to hook into this mechanism, for example to define linting rules related to usage of his custom values and types. On that particular syntax change, I can see how that would have been frustrating. It was requested by ... a person who was running an important project ... and honestly it's how the syntax should have been at the outset. There's another option for this specific syntax issue, which is that There's an LALR(1) parser generator in hobbes (in Anyway, a tool like this can be useful for people in some situations, it's a good idea. |
Also happy Thanksgiving Kai! It's good to hear from you. :) |
@kthielen happy Thanksgiving too! These options you suggested did cross my mind: they're more general solutions which require a few building blocks that represent the entire hobbes parser rules (maybe more). Using a custom parser to rewrite the legacy syntax to the new one looks nice (it still requires a full coverage of hobbes parser rules, if I understand you correctly). But I think we're probably not yet at the stage where the legacy code is too costly to change. I'm a little unsure whether it would cause potential confusions when the legacy code is mixed with the new syntax in the future. Therefore I chose something simpler. The caveat is that a few lexical tokens that are discarded in the current flex/bison parsing context need a reconsideration, e.g. surrounding parenthesis for nested expressions. They're probably not a good candidate as BTW, I was also thinking whether a standalone lint process/daemon would make more sense, making it possible for editor plugins. Anyway it's not happening at the moment. |
Yeah, maybe also your linter idea is orthogonal to the parsing issues since you could use it for "semantic patterns" too. The parser/syntax part of hobbes could really use some TLC. Unfortunately it's always been a lower priority (at least for me) compared to the other features we've accumulated over the years. Some of the ideas there (like user-defined syntax) go against the grain of standard expectations of a fixed grammar (makes things like editor plugins tricky too). OTOH, if we always do things the same way then we'll always have the same limitations. :D |
hobbes language syntax was refined since commit cf789e0d1: it also introduces a different evaluation result for expressions like
if true then 1 else 2 + 3
, because the earlier versions interpret the expression as(if true then 1 else 2) + 3
and the later ones regard it asif true then 1 else (2+3)
.I've added a small lint tool to capture such legacy coding style during loading hobbes modules or evaluation expressions. For some reason I cannot make OSX build pass on travis-ci. Perhaps it would be interested to you and I'd appreciate your comments, @kthielen @smunix
The text was updated successfully, but these errors were encountered: