Re:Topiary: A code formatting engine leveraging Tree-sitter
by cormacrelf on Saturday May 20, 2023 @05:17AM
(#36010447)
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 and you want to format the whole thing. 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. That's not to say the tradeoff might be worth it! Topiary seems like a good idea that could help us collectively spend less time on this kind of thing.
One other thing is the decentralisation of the TS grammar development. There's nothing wrong with people making their own grammars, but the shape of a TS parse tree for any given language changes according to the whims of the hundreds of individuals who seem to be maintaining them out in the wild. Projects like nvim-treesitter maintain their own highlighting queries, and also (AFAIK) manually update refs to commits on the upstream grammar repos to control the pace of change. They have to do this because the queries + the grammar have to be kept tightly in sync, if you refactor the grammar without updating the query file then a million people's neovim installs start spewing errors. And the grammars (largely) aren't controlled by language developers, so they lag behind features. So all this requires development of grammars in concert with all the applications of them. It's not like the LSP which formed a pretty low friction, low churn interface for independent development of all the code analysis servers. (They added features extremely fast, but an unchanged LSP server from 5 years ago probably still works unchanged.)
This situation is mostly acceptable for syntax highlighting in an editor, but maybe not for a code formatting tool that's meant to be authoritative and consistent between developers. Is Topiary going to maintain forks of two hundred grammars with their own queries? It's pretty ambitious. Which is why I'm not surprised they focused on one language, OCaml... it seems infeasible for TS to actually deliver on its potential here.
One other thing is the decentralisation of the TS grammar development. There's nothing wrong with people making their own grammars, but the shape of a TS parse tree for any given language changes according to the whims of the hundreds of individuals who seem to be maintaining them out in the wild. Projects like nvim-treesitter maintain their own highlighting queries, and also (AFAIK) manually update refs to commits on the upstream grammar repos to control the pace of change. They have to do this because the queries + the grammar have to be kept tightly in sync, if you refactor the grammar without updating the query file then a million people's neovim installs start spewing errors. And the grammars (largely) aren't controlled by language developers, so they lag behind features. So all this requires development of grammars in concert with all the applications of them. It's not like the LSP which formed a pretty low friction, low churn interface for independent development of all the code analysis servers. (They added features extremely fast, but an unchanged LSP server from 5 years ago probably still works unchanged.)
This situation is mostly acceptable for syntax highlighting in an editor, but maybe not for a code formatting tool that's meant to be authoritative and consistent between developers. Is Topiary going to maintain forks of two hundred grammars with their own queries? It's pretty ambitious. Which is why I'm not surprised they focused on one language, OCaml... it seems infeasible for TS to actually deliver on its potential here.