Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
Yes. It's typically a fair bit slower than a hand-coded parser. The idea sounds great until you're working on a codebase with 2 million LOC. At that point, the speed of a cold parse is most important, whereas TS is designed for fast re-parsing of a single file. These aren't great numbers but the Rust TS parser is reportedly 2x slower than rustc's https://github.com/tree-sitter/tree-sitter-rust. It's no surprise that you just use the faster option if it's convenient.
It's ironic that just as the excellent https://github.com/ocaml-ppx/ocamlformat is seemingly closing in on 1.0 after ~4 years of development, here comes the implication that it's not good enough.
Oh I totally agree with your sentiment about tree-sitter. That's why I want it to be extended in functionality. It makes so much sense to have a single place where one parser can be written and everybody benefits. Much like language servers.
Where I disagree is that IMO, tree-sitter already is very close to this ideal model. It has incremental parsing. It has great tree querying. Where it needs help is an AST facade over the raw syntax tree, which is very much feasible. rust-sitter[1] does it for instance. Tree-editing and tree construction is also very much doable. I don't think it'd have an impact on grammar construction at all. As for error recovery, I think it could function as a reparsing feature where you can drop down to a manual parser (or even a secondary grammar) that is more tolerant. Or an error recovery function that can be written in any language. tree-sitter already has the ability to use a manual lexer written in native code, so this is not such a stretch.