Eniko (moved ➡ gamedev.place)goddamn writing a recursive descent parser is a lot harder when you wanna do good syntax error recovery
Doug Gregor@eniko @thephd We’ve recently been rewriting the Swift parser, and have some opinions on how to do this well: good parser primitives (“expect this”, “match this”, “don’t go beyond that”, etc.), no diagnostics from parsing itself (represent all issues as missing/unexpected nodes in the tree), and handle diagnostics in a post-pass. The result is really nice and is easy to extend to@new grammar terms. See https://github.com/apple/swift-syntax/blob/main/Sources/SwiftParser/SwiftParser.docc/ParserRecovery.md
Paul Cantrell@dgregor79 I had not seen this. This is magnificent.
Is there any thought of splitting the parser primitives into a separate library? I assume much more maintenance than the team cares to take on, but seems like it could be an amazing resource for other projects.
@inthehands we haven’t seriously considered it, no. To make it reusable, I think we’d want to separate out the part that generates a syntax tree from a grammar (tons of code gen), and then factor out the parser primitives. It’s a lot of work and we’re not really motivated to do it, not because it’s a bad idea (it would be very cool), but because of the opportunity cost. We’d much rather spend our time building more tooling pieces on top of the new parser and integrate them with the main compiler
@dgregor79 Fair, and as expected. And I would totally volunteer to do the library extraction if I didn’t have a family or a job.
Always love these windows into the work you all are doing.