Jinx VS Cwerg

Check out jinx https://jamesboer.github.io/Jinx/

Don't get me wrong, I'm a big fan of automated tests where it makes sense. I wrote a scripting language that I use for my personal game projects, and I never would have been able to do it if it weren't for the battery of tests for every feature, error, and corner case I could think of. But games are rarely like other software, with hard rules about what is "correct" or "incorrect". And it would be a nightmare to try to keep up with designers, constantly tweaking and tuning, so what's "correct" is literally a day to day, constantly moving target.

A second trial for you might be Jinx. Depending on your definition of procedural, Jinx is 100% only procedural. https://jamesboer.github.io/Jinx/

Jinx (embeddable scripting language) works as following:

Feel free to look at my own interpreter, written in modern C++. You're welcome to ask me if you have any questions.

I use my own scripting language more like content, especially for things like one-off events and behaviors. Example: scripting special behaviors for a boss fight, or a room with a unique trap in it, or any other sort of one-off behavior that would be overkill for C++, but too complex for most other types of data-driven content. These days, visual scripting also helps to fill in these gaps between content and procedure.

You're welcome to look at my scripting language Jinx, written in modern C++. Just let me know if you have specific questions. Data flow is JxLexer.cpp -> JxParser.cpp -> JxScript.cpp. Most everything else is implementation details. Also, note the parer is pretty complex, mostly because Jinx has a crazily flexible syntax for functions.

Feel free to look at Jinx if you want an example of what I consider a fairly easy-to-use and integrate scripting system. Obviously, I'm a bit biased since I wrote it.

If you're working in UTF-8 internally, you could just write your own UTF-16 to UTF-8 conversion functions to convert strings at API boundaries. I did this in my scripting language because I didn't want to bring in dependencies.

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