Practical LR Parser Generation · HackerPapers discussions

Practical LR Parser Generation — mentioned by jzimmerman64

Sat, 24 Sep 2022 16:18:52 GMT

Readers who are interested in parsing theory may also enjoy the companion technical report: https://arxiv.org/pdf/2209.08383.pdf as well as a brief users' manual, available here: https://arxiv.org/pdf/2209.08385.pdf

Paper and discussion history. A mention is not an endorsement.

Practical LR Parser Generation — mentioned by jzimmerman64

Sat, 24 Sep 2022 16:16:57 GMT

> back when it was considered impossibly impractical (the "dragon book" said so!) Yes, with some optimizations (e.g., Pager's algorithm), LR(1) can be practical; in langcc we even implement LR(k), and this is also practical for many real-world grammars. However, a key observation is that even LR(k) is not enough for many industrial language features. You may enjoy reading the companion technical report for langcc, which delves deep into the underlying parsing theory and proposes a number of new techniques: https://arxiv.org/pdf/2209.08383.pdf

Paper and discussion history. A mention is not an endorsement.

Practical LR Parser Generation — mentioned by jzimmerman64

Sat, 24 Sep 2022 12:04:41 GMT

> Whereas langcc boasts automatically-generated parsers for the easy-to-parse Python and Go, my old employer has automatically-generated parsers for Ruby, C++, COBOL, and about 100 others. Python may be (comparatively) easy to parse, but Golang is not - it is _barely_ LR(1) with the extensions described in https://arxiv.org/pdf/2209.08383.pdf (notably, semantic attributes and the CPS transformation). > my old employer has automatically-generated parsers for Ruby, C++, COBOL, and about 100 others GLR parsing, as I note in the paper, is very different from pure LR(k) parsing. Are the…

Paper and discussion history. A mention is not an endorsement.