You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a rather newb ReasonML I have found some of my most mysterious syntax errors to be caused by unbalanced parentheses, curly brackets, or square brackets.
While sometimes it will get the line number correct, other times it will go to the end of the block or sometimes the end of the file. I've had the worst results with missing opening [ on lists.
Sorry I don't have a lot of code examples, I've personally turned on RainbowParentheses in vim to see visually when I mess up, but it would be neat if the compiler could do the basic enclosure counting. My own research has shown this can be an interview question or a PhD thesis research topic, so I want to put this as a very light suggestion. GCC as late as 2016 has no such logic in it, nor does LLVM as far as I can tell. Also I don't know if this would go into refmt, merlin, or some other stage. Just putting it out there since it is useful, but as it can be a quite involved problem to do this efficiently I wouldn't want to put this on anyone to truly solve.
IIRC, we already have a similar process that occurs before running the full parser, in order to infer which parens are the opening of ES6 style fat arrow functions. This might be a natural point to print very helpful messages about unbalanced parens.
As a rather newb ReasonML I have found some of my most mysterious syntax errors to be caused by unbalanced parentheses, curly brackets, or square brackets.
While sometimes it will get the line number correct, other times it will go to the end of the block or sometimes the end of the file. I've had the worst results with missing opening [ on lists.
Sorry I don't have a lot of code examples, I've personally turned on RainbowParentheses in vim to see visually when I mess up, but it would be neat if the compiler could do the basic enclosure counting. My own research has shown this can be an interview question or a PhD thesis research topic, so I want to put this as a very light suggestion. GCC as late as 2016 has no such logic in it, nor does LLVM as far as I can tell. Also I don't know if this would go into refmt, merlin, or some other stage. Just putting it out there since it is useful, but as it can be a quite involved problem to do this efficiently I wouldn't want to put this on anyone to truly solve.
Program analysis via graph reachability -> http://www.dtic.mil/get-tr-doc/pdf?AD=ADA332493
and a later paper with an efficient algorithm for doing such CFL analysis:
https://www.cs.purdue.edu/homes/peugster/EventJava/Dyck-Trees.pdf
Or just stack, pop and count them. 🔢 😸
The text was updated successfully, but these errors were encountered: