So this has been discussed but this is still not ininteresting: may be this is not needed for the Lua language itself (which has its own syntaxic representation which is still sufficient), but for formal analysis of the language, and for implementing it (e.g. in an interpreter, in its VM, or in a compiler), that Lua language has to be transformed into another more powerful language (where conformance checks can be made, as well as all optimizations at compiler time or dynamically at runtime). You can implement it in various ways. Lua proposes its opcode machine, more or less stack based (even if there's some data storage described as "registers"), but you can as well represent a Lua program in a lamda calculus form.
Don't reinvent the wheel: we have a wellknown language for it: Lisp.
And Lisp can also be extremely efficient and fast, if you don't restrict its internal representation to be **just binary trees** with terminal nodes and binary nodes containing only two pointers. You can also implement it by using more types of nodes, for example B-tree pages, which will allow much better data locality and very fast processing, and which is even much easier to transform to another native assemble code than any invented virtual instruction set. With B-tree pages+terminal nodes, you can express both the program code, and all the data that this code handles, and make all transforms of the tree mixing these two kinds of nodes, in order to improve locality, determine constants and precompute them (avoiding also false branch predictions made in many "optimizers").
And implementing a Lisp-based VM is even much easier than a Lua VM... It also allows you to use unlimited "opcodes" (implemented as terminal nodes in Lisp's lists). Lisp lists can also naturally represent any Lua table (if you've used B-trees this is equally compact and fast, but allows easier memory management because B-tree pages have fixed sizes and can be allocated efficiently from a limited set of pools, and you an also easily compact these pools to reduce the global memory footprint on the system, just like what you do in relation database stores where B-trees are very efficient in terms of compacity, speed of accessn data locality, cachability...).
