lexgen
A fully-featured lexer generator, implemented as a proc macro (by osa1)
parsegen
An LR parser generator, implemented as a proc macro (by osa1)
lexgen | parsegen | |
---|---|---|
4 | 2 | |
60 | 15 | |
- | - | |
5.9 | 1.5 | |
3 months ago | about 1 year ago | |
Rust | Rust | |
MIT License | MIT License |
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
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.
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.
lexgen
Posts with mentions or reviews of lexgen.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2023-05-06.
-
How are macros dealt with for incremental compilation?
Indeed this is the problem I'm having with my proc macro crates lexgen and parsegen. In the case of lexgen, the proc macro is actually quite fast for realistic inputs, but the compiler spends a lot of time checking and generated code with cargo check (which I suspect rust-analyzer also uses). In the case of parsegen the proc macro does some analyses and takes some time. In both cases I have to split my proc macro code (not the proc macros, the code that uses the proc macros) to separate crates so that they won't be recompiler/re-analyzed as I work on the code.
-
If you're not using a lexer generator for your compiler, why?
My lexer generator can handle unicode too. It's not too difficult to implement.
- A fully-featured lexer generator for Rust, implemented as a proc macro
parsegen
Posts with mentions or reviews of parsegen.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2023-05-06.
-
How are macros dealt with for incremental compilation?
Indeed this is the problem I'm having with my proc macro crates lexgen and parsegen. In the case of lexgen, the proc macro is actually quite fast for realistic inputs, but the compiler spends a lot of time checking and generated code with cargo check (which I suspect rust-analyzer also uses). In the case of parsegen the proc macro does some analyses and takes some time. In both cases I have to split my proc macro code (not the proc macros, the code that uses the proc macros) to separate crates so that they won't be recompiler/re-analyzed as I work on the code.
-
If you're not using a lexer generator for your compiler, why?
I'm working on my own lexer and parser generators, and I'm trying to understand why some projects don't use lexer and parser generators and use hand-written lexers and parsers.
What are some alternatives?
When comparing lexgen and parsegen you can also consider the following projects:
logos - Create ridiculously fast Lexers
hush - Hush is a unix shell based on the Lua programming language
clojurust - A proof of concept version of Clojure in Rust.
micro-mitten - You might not need your garbage collector
crafting-interpreters-rs - Crafting Interpreters in Rust