packcc
cparse
packcc | cparse | |
---|---|---|
2 | 14 | |
317 | 47 | |
- | - | |
4.3 | 10.0 | |
9 days ago | over 1 year ago | |
C | C | |
GNU General Public License v3.0 or later | 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.
packcc
-
A glimpse into the universe where Windows died with the 1980s
There are languages with perfectly clean grammars which can't be parsed by yacc because they aren't LALR(1).
I agree that a command processor should have a grammar that can be expressed in a well-known formalism, and its parser generated by a parser generator.
I agree that both POSIX shell and CMD.EXE are flawed because that isn't true.
What I'm disagreeing with, is that it is important that the grammar formalism be LALR(1) in particular, and that the parser generator be yacc in particular.
Suppose I have a Packrat parser generator. [0] And my command processor has a nice clean PEG grammar. And I use the Packrat parser generator to generate the parser of my command processor. That grammar quite possibly isn't LALR(1), and hence yacc in particular won't be able to generate a parser for it. But what's the problem with that? If it is a problem at all, it is a very different problem than the problem that CMD.EXE and POSIX shell have
[0] e.g. https://github.com/arithy/packcc
- PackCC a PEG parser generator for C
cparse
- clex is now thread-safe and instance-based, a lexer generator for C
-
Show HN: Clex is now thread-safe and instance-based A lexer generator for C
https://github.com/jafarlihi/clex
I very recently updated clex to be instance-based (instead of being a single global instance) and thread-safe based on previous feedback.
clex lets you programatically generate lexers in your C program without going through extra intermediary generation/compilation step, and now you can have more than one in your application!
There’s also cparse: https://github.com/jafarlihi/cparse
It lets you generate LR(1) and LALR(1) parsers in much the same way, and it uses clex under the hood. It’s currently not updated to the latest version of instance-based clex but it is in my plans to do so soon.
Feedback and contributions are appreciated!
- GitHub - jafarlihi/cparse: cparse is an LR(1) and LALR(1) parser generator for C
- Cparse: LR(1) and LALR(1) parser generator for C
- Show HN: cparse – LR(1) and LALR(1) parser generator in C
- Show HN: Cparse – a simple parser generator for C – now supports LALR(1)
- Show HN: Cparse is a simple LR(1) parser generator for C
- GitHub - jafarlihi/cparse: cparse is a simple LR(1) parser generator for C
What are some alternatives?
rust-peg - Parsing Expression Grammar (PEG) parser generator for Rust
tklgen
npeg - PEGs for Nim, another take
mewa - Compiler-compiler for writing compiler frontends with Lua
PeppaPEG - PEG Parser in ANSI C
parsertl-playground - A web based playground for parsertl/lexertl