PeppaPEG VS packcc

- Having a PEG parser in ANSI C can benefit whoever is developing a parser, as adding C bindings for other programming languages are not too difficult.

And after SIX months' development, my project is now kinda feature complete. It's named Peppa PEG and you can find it here: .

I have learned quite a lot during the journey of creating it, such as gdb, valgrind, cmake, etc. And I wouldn't make it to the end without learning from some awesome projects, such as pest.rs, cJSON, etc.

To give you a glance how the library is used, here are some examples:

- Write an INI Parser using Peppa PEG: [ini.h](https://github.com/soasme/PeppaPEG/blob/main/examples/ini.h).

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