# LuaC

| We're not kidding here; LuaC might have its uses, but it comes with a lot of strings attached. Don't use it. (for experts) Don't use it yet. |

| Although LÖVE accepts bytecode (because well, the VM does) we don't actually support it, if you have problems with bytecode, try plaintext before reporting bugs. |

LuaC is tool which takes a lua source file and parses it into lua byte-code.

Sounds useful? Keep reading.

Lua byte-codes are not part of the Lua specification but rather a practical result of the LuaVM's design. The LuaVM is also not a part of any standardized specification, for it too is an implementation detail. The only part of Lua that has a standardized specification is the language itself, and the CAPI. Nothing else.

The incompatibility of the byte-codes stems from this. Since there is no specification for Lua byte-codes, and they are not meant to be ported between different builds of Lua, there's no need to insulate the byte-codes from the vagaries and tribulations of the compiler. The upshot of this is that the compiler is free to rearrange the various `struct`s and `enum`s upon which the VM relies as deems fit (usually for efficiency), the down side is that any byte-code is potentially idiosyncratic to the exact build of lua that created it.

"But then, why create LuaC?", a question with a simple answer: One possible build configuration of Lua is parserless (an ultra-small size Lua build), which has the down side that it is unable to process source files on its own; it must be given pre-parsed source files...which is to say, byte-codes. The same limitations apply, though; the build of LuaC used must match the VM. A brittle solution, but tolerable given the circumstances.

Category:

- Lua