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.
-
-
Replying to @sebmck
I’ve always assumed it was bc once they encountered that error they couldn’t parse the rest of the document and find the end position. Might be a naive take on it though.
2 replies 0 retweets 0 likes -
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.
1 reply 0 retweets 0 likes -
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?
2 replies 0 retweets 0 likes -
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.
1 reply 0 retweets 0 likes -
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.
2 replies 0 retweets 3 likes
Yeah, Acorn has a loose parser but that’s because it was specifically designed for usage in ternjs (in an editor). I still think the barrier to integrating with LSP is very high. Babel will never run in an editor, so no incentive for a tolerant parser.
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.
he/him 