This is the README for the cwal2 project:
https://fossil.wanderinghorse.net/r/cwal2
This project is experimental, very incomplete, and of alpha quality. It is not intended for anyone's use beyond its own developer's.
cwal2 is a reimplementation of cwal, the Scripting Engine Without a Language. In short, it provides a basis for scripting engines and certain garbage-collection use case. It does not provide a scripting engine, but pieces commonly used in building one:
An abstract type system akin to JavaScript's.
A garbage-collected memory management model.
cwal2 is still very much in development and undocumented. All current code experimental, subject to change in any ways. If this experiment pans out, it will get the usual full API docs all of my public-facing projects have. Until then, though... it's an experiment.
Though fundamentally similar to v1, the most significant differences from its predecessor include:
Requires C11, most significantly for mutex APIs and (since we're using C11 anyway) "generics" (pale shadows of C++ templates, but still interesting).
Changes the central focus from trying to squeeze every byte of memory out of it to making it more robust and mature. It allocates far more often but still recycles most of its memory, so aggregate per-value costs are low.
It adds a layer of abstraction between clients and values: references are full-fledged objects instead of just a number, making for a far more robust-against-client-misuse model. For example, whereas previously a double-unref could go unnoticed for arbitrarily long, and invariably led to grief and heart-ache, similar shenanigans will now typically invoke a double-free crash (or similar) at the point of the second unref. The reference objects belong to a single context ("engine" in v1 parlance). Clients no longer work directly with "value" objects, but instead work with "reference" objects.
Its "garbage collection roots" no longer do double-duty as storage for variables. Scope-level storage will be in an optional higher-level API in v2.
Array and Hash types no longer derive from Object at the engine level, though whether this is a feature or a bug is as yet undetermined.
Goals of this Project (same as v1, basically, minus the aspect of treating RAM as a rare and holy resource):
Provide an easy-to-use, flexible, and robust basis for scripting engines and applications which have similar value-type and gc needs.
Once the base is proven, implement a language or two on top of it. Version 1 has had, as of 2022, four different languages written for it, two of which (s2 and whcl) are currently maintained and one of which (s2) is in the strong lead for re-implementation in cwal2.
Non-Goals:
To become "the next big thing" or anything close to it.
To be on the cutting-edge of script engine research.