EDIT: The language looks pretty cool in general. I'm not a huge fan of the recursion syntax. In particular, the `this` keyword seems to just refer to the current function object, which is confusing since in other languages that usually refers to the object a method belongs to. Further, the choice of immutable lists as the default data structure is odd -- arrays would be much more performant (and are the usual choice for scripting languages anyway).
A few points:
1. I'd like to see the FFI implemented natively (i.e. by declaring in Solid and registering through C code/macro, instead of relying on object file parsing). Then it'll be extremely useful in a bare-metal microcontroller environment.
2. Namespacing is needed -- I don't really want `parse_xxx` or `ast_node` in my global namespace!
Also, what did you not like about the Lua object model?
Lua's whole table-metatable system always felt awkward to me, what with the magic names for operators. It's really not so bad, I just didn't see any reason to spend time learning something that felt awkward and archaic to me when I could make something that seemed a bit cleaner.
However, despite taking some 200K compiled, Lua does give you a lot of things for that dirtier object system or origin (or other things you'll dislike).
Some of those things are already planned by yourself, some you'll find out that you need only with enough usage, and others may be outside the scope of Solid. A partial list:
0. A reasonably efficient GC
1. Very fast portable interpreter - faster than most other portable interpreters (e.g. Ruby, Python) with comparable dynamic behaviour
2. A crazy fast JIT compiler (LuaJIT2) fully compatible with that interpreter that rivals compiled and optimized static languages, and is available for many common architectures (x86, AMD64, various PPC, various ARM)
3. Useful built in data type like a dictionary/array ("table"), strings and floating point math, C user definable structure.
4. A vast ecosystem, different in nature than Python's or Ruby's (geared towards embedding rather than direct use), but definitely there and definitely useful.
Once you implement the infrastructure required for these, you'll find out that magically, you're not much shorter than Lua after all (if at all), and that some things just cannot be matched (JITting. Unless you're the 10 people or so that have made PyPy happen. Or you are Mike Pall).
Still, it's a nice little language, and seems quite well written (though the choice of vm.regs[255] for a return value is likely to bite you at some point - make a macro for that, at the very least, to guard you against a type of 244 or 266 or 2555 or any other random number).
And if you are looking for inspiration for some features, another interesting and practical little language is Aardappel's Lobster: https://github.com/aardappel/lobster ; I really like the fresh approaches that he takes.
