| packcc | npeg | |
|---|---|---|
| 2 | 2 | |
| 317 | 321 | |
| - | - | |
| 4.3 | 5.1 | |
| 8 days ago | about 1 month ago | |
| C | Nim | |
| 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
npeg
-
Pratt Parsers: Expression Parsing Made Easy
Ha, nice to see this on HN: this article was pretty helpful to me to understand the concept a few years back when extending my PEG parsing library [1] with a Pratt parser; this mitigates the problem of PEG parsers not allowing left recursion and allows for a much more concise notation of grammars with operator precedence. Thank you Bob:
1. https://github.com/zevv/npeg
-
Nim v2.0 Released
Ones that have not been mentioned so far:
nlvm is an unofficial LLVM backend: https://github.com/arnetheduck/nlvm
npeg lets you write PEGs inline in almost normal PEG notation: https://github.com/zevv/npeg
futhark provides for much more automatic C interop: https://github.com/PMunch/futhark
nimpy allows calling Python code from Nim and vice versa: https://github.com/yglukhov/nimpy
questionable provides a lot of syntax sugar surrounding Option/Result types: https://github.com/codex-storage/questionable
ratel is a framework for embedded programming: https://github.com/PMunch/ratel
cps allows arbitrary procedure rewriting to continuation passing style: https://github.com/nim-works/cps
chronos is an alternative async/await backend: https://github.com/status-im/nim-chronos
zero-functional fixes some inefficiencies when chaining list operations: https://github.com/zero-functional/zero-functional
owlkettle is a declarative macro-oriented library for GTK: https://github.com/can-lehmann/owlkettle
A longer list can be found at https://github.com/ringabout/awesome-nim.
What are some alternatives?
rust-peg - Parsing Expression Grammar (PEG) parser generator for Rust
awesome-nim - A curated list of awesome Nim frameworks, libraries, software and resources.
PeppaPEG - PEG Parser in ANSI C
jsony - A loose, direct to object json parser with hooks.
cparse - cparse is an LR(1) and LALR(1) parser generator
futhark - Automatic wrapping of C headers in Nim
torrentinim - A very low memory-footprint, self hosted API-only torrent search engine. Sonarr + Radarr Compatible, native support for Linux, Mac and Windows.
nlvm - LLVM-based compiler for the Nim language
mummy - An HTTP and WebSocket server for Nim that returns to the ancient ways of threads.
FrameworkBenchmarks - Source for the TechEmpower Framework Benchmarks project
pixie - Full-featured 2d graphics library for Nim.
questionable - Elegant optional types for Nim