he/him 
Why do most (at least JS) parsers restrict syntax errors to a single position? eg. only a single column/line, rather than having a range of start/end? The errors would be a lot richer.
-
This rarely, if ever, happens in practice—a good parser tries as hard as it can to “recover” from input it doesn’t understand. That’s how, in your favorite editor, you can type something totally bananas, then go back to writing valid JS and only the bad part has red squigglies.
I'd say it's the opposite. IDE/editor parsers are the minority. None of the parsers I've ever worked with had to care about parsing invalid input. Why would it need to?
-
-
What are some parsers that don’t get used in an editor? I would think if you have a language that you want to both write and compile, you’d want the parser to work for both steps—providing language service and then actually producing some kind of emit.
-
I get the sense that in the OSS world, tolerant parsers were novel until Roslyn and TypeScript set the example. For example, we had to make https://github.com/Microsoft/tolerant-php-parser … to get better editor support for PHP.
- 1 more reply
New conversation -
-
-
I guess it's not a necessity, but a fairly good reason to do this is that enables telling you about multiple parse errors in a single compilation pass. Similar to how you want your test runner to tell you every test that fails, not just stop after the first failure.pic.twitter.com/srDrTf3Uek
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.