Post #2479124

2026-05-09 15:11 UTC

@olynch@mathstodon.xyz - Parser error recovery in the literature is generally based on a formulation of the problem that seems more at-home in the era of punch cards and terminal transmission errors. - Most nontrivial error recovery mechanisms in the literature require either using a table-based parser or a programming language with very impressive non-local control flow constructs (which you might not want to use for performance reasons, even if your language has them). - Prior work on both error recovery and incremental parsing was done using assumptions that don't match up well with the current environment of LSP integrations into text editors.

Replies (1)

@olynch@mathstodon.xyz 2026-05-10 14:48

@zwarich@hachyderm.io This thing about grammar based testing is very interesting. I think it's probably a good idea to write down a grammar and then try to do property-based testing on the handwritten parser by seeing if it can parse an arbitrary string sampled randomly from the grammar, and it gives back the same tree that the grammar gave; this seems related to what @MartinEscardo@mathstodon.xyz was suggesting but in a bit of a different direction. One of my colleagues recently wrote a property based tester for fnotation, but it was manually written; it would be much better to generate this automatically from a declarative spec. Though... there still is a tricky thing here which is that if you want to test your precedence parsing, you have to generate strings that have some, but not all parentheses, so you have to express precedences numerically in the grammar still.

Open ##2479125