Zen itself is only about 15,000 lines of C++, using ZooLib to run on Mac, Windows and Linux. It uses a tuplebase to store configuration and state, and uses the same tuplebase as the communication medium between its components.

To earn its stripes as the foundation for a smart home its higher-level behavior needs to be customizable. Some of that customizability can be captured as data-driven C++ code, but there are always edge cases to deal with, and C++ is not as malleable as I'd like when experimenting. So for a long time I'd been looking for an embeddable programming language that could talk with the C++. I've considered SIOD, but I'm just not a Scheme person. And although Javascript is a much nicer language than you might believe from only having seen its use in web pages, the various open source implementations are quite hard to incorporate into an application that's not the web browser that spawned them.

Lua is written in ANSI C, not requiring much even of the standard C library. It took only a couple of hours from downloading Lua to having it compiled using GCC on Linux and CodeWarrior on Mac. Actually connecting it to C++ and to Zen took a bit longer, but only because its scheme for sharing data between C++ and Lua is unique in my experience and took some thought to fully grok.

There is an excellent book, "Programming in Lua" whose first edition is available online and the second edition in printed form.

Lua supports a small range of data types, inluding the usual number, string and booleans. More complex structures are represented as what Lua calls tables, which are very like a blend of LISP s-lists and a-lists, and thus map nicely to ZooLib's tuples.

Lua's controlling mechanisms themselves use tables, so overriding library functions and global and function scopes use the same techniques as working with a program's own data structures.

Zen compiles Lua code that's kept in its tuplebase as that code is modified, and when the code is invoked provides access to state, which can be inspected and modified by Lua code. Reads from state variables are trapped and the code's dependency on those variables is noted so that external changes to those variables can cause the code to be re-run. This is much simpler than the scheme I initially implemented where each Lua function had to be declared in its own tuple, and its dependencies noted in that tuple.