ocamlformat
rust-sitter
ocamlformat | rust-sitter | |
---|---|---|
2 | 6 | |
600 | 570 | |
0.8% | 2.3% | |
8.7 | 5.3 | |
17 days ago | 17 days ago | |
OCaml | Rust | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
ocamlformat
-
Topiary: A code formatting engine leveraging Tree-sitter
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.
-
Is there any way to format mll/mly files?
Ocamlformat does not - issue has been open since 2019
rust-sitter
-
Writing a Debugger from Scratch: Breakpoints
This is a great series!
I noticed that the author was using https://github.com/hydro-project/rust-sitter as a parser. Which is based on https://tree-sitter.github.io/tree-sitter/. I've been hearing about Tree-sitter a lot recently, so I dug into it.
Tree-sitter is a tool for generating fast, incremental parsers. In particular, the algorithm is suited towards writing "language servers" for IDEs, which re-parse code incrementally as the user works. These kinds of incremental parsers have historically been a huge problem. It looks like Tree-sitter is an enormous practical advance in this area.
And discovering that there's a way to use Tree-sitter from Rust is fantastic. From the post:
#[rust_sitter::language]
-
Topiary: A code formatting engine leveraging Tree-sitter
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.
[1]: https://github.com/hydro-project/rust-sitter.
- GitHub - hydro-project/rust-sitter: Use Tree Sitter to parse your own languages in Rust
- Rust-sitter: Define your entire tree-sitter grammar in Rust code
- Rust-sitter: Define your entire tree-sitter grammar on idiomatic Rust
- Rust Sitter: create efficient parsers in Rust
What are some alternatives?
reason - Simple, fast & type safe code that leverages the JavaScript & OCaml ecosystems
tree-sitter-c2rust - A fork of Tree Sitter with a pure Rust runtime for WASM support
mirage - MirageOS is a library operating system that constructs unikernels
python-dbg - Python debugger experiments
merlin - Context sensitive completion for OCaml in Vim and Emacs
nvim-treesitter - Nvim Treesitter configurations and abstraction layer
google-drive-ocamlfuse - FUSE filesystem over Google Drive
Crafting Interpreters - Repository for the book "Crafting Interpreters"
bap - Binary Analysis Platform
tree-sitter-rust - Rust grammar for tree-sitter
ocaml - The core OCaml system: compilers, runtime system, base libraries
pyre-check - Performant type-checking for python.