Yes, very much so. If you've embedded lua before it's very easy to do the same with duktape. A few conventions are different -- for instance stack indicies are 0-based instead of 1-based (mirroring the difference in JS vs Lua) and some of the strategies for interfacing with native-code objects is different (JS prototypes aren't exact analogues to Lua metatables, etc)
Absolutely, the original motivation was to have a Lua-like implementation for Javascript.
And thank you! I've wanted this for years, but haven't yet gotten up the courage to actually tackle it. ES5.1 is big and ES6 is massive.
I really want to applaud your effort. Are you accepting donations?
Thanks! At the moment no, but send me an e-mail if you use Duktape somewhere :)
I immediately thought of Lua as well. A fine choice, Lua has the best C FFI I've ever worked with. I love everything about this.
Does Lua work well with multiple threads?
Lua has full support for creating multiple interpreter instances (ie. there are no global variables, and it's totally re-entrant). But interpreter instances are not thread-safe. So the way to support multiple threads is to have completely independent interpreters running in different threads.
Thanks. Any idea as to the footprint of these instances?
I use this approach in Fire★ (http://www.firestr.com). Lua vm instances are tiny. There is a reason lua is used even in systems like nintendo DS
You can make a Lua interpreter thread safe by adding a GIL. There is implicit support for this in the code: the interpreter invokes lua_lock/lua_unlock at the proper places, the default Lua implementation just has them NOP'd out. Adding the thread primitives is up to you, however.
when you have multiple threads, isn't the idea to share data between threads? I haven't really worked with embedded lua before - does lua help with that?