parsejevko.c VS Cwerg

I tried sketching one out in Python: https://github.com/jevko/parsejevko.py ; one in C: https://github.com/jevko/parsejevko.c ; one in Java: https://github.com/jevko/parsejevko.java ; one in Scheme: https://github.com/jevko/jevkostream.scm (that's a streaming parser stub, more fleshed out one in JS is here: https://github.com/jevko/jevkostream.js ); and there are some implementations of Jevko formats and other related things in the GitHub organization: https://github.com/jevko

Perhaps these have already been dealt with and I'm missing critical information. If so, my apologies. Great work, in any case.

[1] https://github.com/robertmuth/Cwerg/tree/master/FrontEnd#dis...

Cwerg has backend that can be used as JIT and is written with readability in mind. Additional documentation can be found here: https://github.com/robertmuth/Cwerg/tree/master/Docs

I defined a basic ISA-like IR for Cwerg. It has unlimited registers and no constraints on immediates.

entire compiler front end ast nodes

I was also going down the path of bike shedding concrete syntax for my language Cwerg before pulling the plug on that effort and just using s-exprs. I managed to make the s-expr quite succinct by carefully choosing the order of arguments so I can omit optional ones. Also very helpful was to use square brackets for list, e.g. (call fun-name [arg1 arg2]). This simplifies parsing a little bit and is easier on the eye. Here are some Code Examples

I am iterating over the languages features for Cwerg's Frontend which aims to be a low level language with about the complexity of C but with some of the comforts of modern languages. I am especially happy with the choice of adding sum types. Relative to C the current feature set looks like this: Removed: * arrays decay to pointers * bitfields * separate compilation (more of a backend issue) * pre-processor * varargs * implcit type conversions * (untagged) unions * ++/-- * comma operator * implicitly nullable pointers * goto