s2: cwal's 2nd scripting language

(Actually, it's the 3rd, but (A) the first one was a throwaway prototype and (B) S3 is the name of a chip manufacturer.)

cwal s2 Modules Client
CW: box rad 0.5cm "cwal"
line <-
S2: box same "s2"
line <- up 0.5 right 0.5
MOD: box same "Modules"
arc -> from MOD.w to CW.n
line <- down 0.5 right 0.5 from S2.e
CL: box same "Client"
line -> from CL.n to MOD.s
arc -> cw from CL.w to CW.s

s2 is a cwal-based scripting engine, th1ish's successor, and aims at the same niche: a small platform for adding scripted test harnesses to C libraries. s2 provides a JavaScript-like environment and is feature-complete. Experience with th1ish (which s2 surpasses in almost every way) has shown that the underlying engine can in fact do quite a lot more than just run unit tests, such as generating whole web sites. Aside from scripting test harnesses, it can be used for general-purpose scripting for a variety of applications or libraries, provided its built-in limits are respected (namely, it is strictly single-threaded, has highly unconventional symbol lookup rules, and in some places sacrifices performance in favor of a smaller memory footprint).

s2 is intended to be embedded directly into client projects, as opposed to being provided as an external library (though it can be used that way, too, of course), and distributes as 2 source files (one header and one C file) which clients simply compile right in their project. To build this distribution, simply run "make amal" from the s2 subdirectory of the source tree. The distribution also includes a shell, known as s2sh, which is trivial to extend by clients using C, scripts, or loadable modules (DLLs).

s2, as of this writing (20141207), implements features undreamed of when the cwal project was started, pushing it well past any initial visions for the code. In particular, subtle refinements in the garbage collection in November/December 2014 have essentially ended any concerns i formerly had about the viability of the GC core. (That's not to say it's bullet-proof, but the biggest of the known GC death-traps have been adequately resolved.) That said, there is still plenty of room for experimentation and the cwal/s2 code bases have proven to be relatively open to experimentation.


Those documents are "the" place for all information about s2.


s2 includes a header-only C++ cwal/native type conversion layer which, using only template voodoo, literally converts near-arbitrary C/C++ values, functions, methods, non-function members, and constructors to cwal callback functions (resp. accessor/mutator functions) with complete type- and NULL-pointer safety using the magic of C++ templates. It includes a mechanism for defining complex callback dispatching rules, created using only typedefs, to route script-based calls to one of any number of potential native functions. See s2/cwal_convert.hpp for details and s2/mod/sample_cpp/sample_cpp2.cpp and s2/mod/sample_cpp/sample_cpp.s2 for examples. While it currently lives in the s2 directory, it's not dependent on s2, and can work with any cwal client code. The C++ layer saves so much work (writing and testing code) that it's a compelling option for writing bindings even when the rest of the host project is pure C.