| 10 Dec 2025 |
 rosssmyth | I've written several parsers in Rust and TBH for best error handling recursive descent will always win. | 16:26:03 |
| rosssmyth | Chumsky is my favorite library though | 16:26:13 |
| rosssmyth | * I've written several parsers in Rust and TBH for best error handling hand-rolled recursive descent will always win. | 16:26:20 |
| rosssmyth | Pratt parsing is nice | 16:26:41 |
| rosssmyth | https://matklad.github.io/2020/04/13/simple-but-powerful-pratt-parsing.html | 16:27:05 |
| rosssmyth | Why do you need a library for that? | 16:27:42 |
| rosssmyth | They integrate just fine | 16:28:05 |
 kloenk | Friend looked at the lib for it and was very unhappy. Not looked myself into it. Mostly happy with logos and hand rolled conversion into rowan | 16:28:48 |
| rosssmyth | Yeah my latest project has a lexer that is just a copy of Rustc's lexer with my tokens in it, ungrammar for the cst data structures, and then hand-rolled parser. | 16:29:58 |
| rosssmyth | Logos is cool though | 16:30:09 |
| rosssmyth | Used it before | 16:30:14 |
| rosssmyth | The thing about parsing is that perf doesn't really matter that much, it's such a small amount of time unless you really mess it up. Better to focus on making it have really good errors | 16:32:12 |
 piegames | In reply to @rosssmyth:matrix.org
The thing about parsing is that perf doesn't really matter that much, it's such a small amount of time unless you really mess it up. Better to focus on making it have really good errors narrator voice indeed it is really messed up | 16:34:30 |
| piegames | Due to unfortunate design decisions made (or rather, not made) back when I was in Kindergarten, parsing is on the critical path for evaluation time | 16:35:23 |
| rosssmyth | amazing | 16:35:33 |
| rosssmyth | If you want the highest performance possible, larlpop will be hard to beat. But recovery is bad so it would be difficult to get good diagnostics out of it. | 16:43:50 |
 helle (just a stray cat girl) | what is the process if we need to do a backport of a patch (or other proposals of how to handle this one)
this as nixpkgs mdbook 0.5.0 update depends on https://gerrit.lix.systems/c/lix/+/4653 being in
see https://github.com/NixOS/nixpkgs/pull/462777#issuecomment-3637993347 & https://github.com/NixOS/nixpkgs/pull/467009 | 16:50:39 |
 Qyriad | In reply to @piegames:flausch.social
narrator voice indeed it is really messed up something something C++ parsing… | 17:18:05 |
| piegames | that too, but that's not even what I meant | 17:18:20 |
 KFears (they/them) | In reply to @piegames:flausch.social
Due to unfortunate design decisions made (or rather, not made) back when I was in Kindergarten, parsing is on the critical path for evaluation time Is that because parsing is so unbearably slow, or is there a more cursed reason? | 17:18:25 |
| Qyriad | In reply to @piegames:flausch.social
Due to unfortunate design decisions made (or rather, not made) back when I was in Kindergarten, parsing is on the critical path for evaluation time we would like to see benchmarks on this… we'd honestly sooner suspect filesystem IO as a bottleneck over parse-time | 17:18:48 |
| Qyriad | In reply to @piegames:flausch.social
Due to unfortunate design decisions made (or rather, not made) back when I was in Kindergarten, parsing is on the critical path for evaluation time * we would like to see benchmarks/profiles on this… we'd honestly sooner suspect filesystem IO as a bottleneck over parse-time | 17:19:17 |
| Qyriad | (having looked at profiles of eval before, but not in a while) | 17:19:29 |
| piegames | no, parsing is super fast, mostly thanks to horrors, it's just that Nixpkgs is 3.6MLOC over 40k files and every single NixOS eval loads a good chunk of that, realistically multiple times. The main issue is that caching was never a thought in the architecture and adding it afterwards is really tricky | 17:21:27 |
