4 ms·
As Anders said near the end of the video, if you want to know more, look at the source code[1]. Speaking as someone who's worked on it (so I'm biased), I feel i
by wwwigham 10y ago
As Anders said near the end of the video, if you want to know more, look at the source code[1]. Speaking as someone who's worked on it (so I'm biased), I feel it's pretty easy to jump in and edit (though I'd advise new people to avoid the typechecker unless you feel particularly adventurous, it's a multi-thousand line long monster file). There are piles of easy issues[2] that are looking for community members to work on them.
By the way - one of the most meaningful comments he made in this talk (to me) was when he said that your parser had to "parse more than the allowed grammar" so you can provide better error messages. Compilers are, ultimately, tools for developers - so developer experience is tantamount. This, I've found, is so very very true in any smaller projects I've worked on, and is easily one of the first things neglected by some of my more algebraically inclined peers (who are very satisfied with a perfect ABNF and a parser which strictly adheres to it).
[1] https://github.com/Microsoft/TypeScript https://github.com/Microsoft/TypeScript
[2] https://github.com/Microsoft/TypeScript/labels/Effort%3A%20Easy https://github.com/Microsoft/TypeScript/labels/Effort%3A%20E...
- seanmcdirmid 10y agoI've developed a couple of cool tricks to get very error tolerant parsers (I design/build live programming languages). We can go pure shunting yard (precedence parser), which will basically parse anything since it doesn't rely on grammar rules. Even if going with grammar based parsing (they are convenient), braces can be matched on tokens in a pre-pass before parsing occurs, eliminating an entire class of difficult to deal with errors, and allowing for brace stickiness in an incremental edit context; no need to rebalance because someone typed an opening paren without brace completion! Though I can't help but think that someone will eventually develop an NN-based PL parser that will be much more error tolerant than straight grammar-based implementations could ever be.
- infinite8s 10y agoDo you have those tricks written up anywhere?
- seanmcdirmid 10y agoNot really. I haven't taken the time to do any analysis given that they are always details in the languages I'm building (which are written up). I gave a talk about this at Parsing SLE (2013?) but I guess it didn't need a PDF. They are really simple ideas (really, pre match your braces, I'm sure I'm not the first one to do that!), I'm not sure they are publishable.
- ejanus 10y agoI would like to see a codebase where this idea is used. I am playing around shunting yard ...