3 ms·
When processing "pi = 3", I'd rather have the error "cannot assign to constant" than "unexpected token =". Generally, whenever I write a parser+checker, I try
by Gehinnn 3y ago
When processing "pi = 3",
I'd rather have the error "cannot assign to constant" than "unexpected token =".
Generally, whenever I write a parser+checker, I try to have a very relaxing parser and then all the checks in the checker.
- PhilipRoman 3y agoIIRC some compilers have taken this to the extreme, adding parsing rules for outright invalid syntax like missing semicolons, so that they can give cleaner error messages.
- cellularmitosis 3y agoSwift applies this across language versions as well. You'll see error messages like "fooWithBar() has been renamed to foo(withBar:)".
- int_19h 3y agoIt's not just the cleaner error messages - if possible, you want to recover from syntactically invalid input at some point so that you can 1) detect errors that follow, but 2) more importantly, do NOT show errors past the point where the original error has recovered. This last bit is especially important in the context of visual dev tooling like IDEs and other smart editors where intermediate states involve missing semicolons, unmatched braces etc all the time. Roslyn (C#, VB) is one specific example of a parser where this approach is pervasive.
- PhilipRoman 3y agoHaving recovery points in a grammar is a really nice thing. I was writing a parser for a lisp-like language and turns out it's surprisingly difficult to come up with robust heuristics for parser recovery. People indent lisp code in various ways but eventually I got something that works most of the time. My approach was indentation based, seeking to the next location with compatible number of spaces/tabs at start of line.