XNua is split into two seperate parts, the runtime simply refered to as XNua and the compiler that takes lua files and produces .NET Assemblies, the compiler is currently an XNA Content Pipeline but I'm also likely to release a standalone compiler pretty soon (I already have it, its just needs some cleaning and removing its dependecy on XNA).

 

Most people will be interested in the runtime part, as its the bit you interact with most of the time. Its contained in the .NET Assembly XNua.dll and there are specific version for both x86 and 360 (which probably isn't strictly nessecary). Each Lua byte code instruction has been converted to a series of IL instructions by the compiler, the assemblies produced reference XNua.dll which provide the runtime library support.

 

The two basic types are LuaValue and LuaReference, a Lua VM register is a LuaValue which is a dynamic type reprensenting a number or a LuaReference. A LuaReference is either a pointer to nil (Lua equivelent of null), boolean (via TrueClass and FalseClass), a LuaTable or a LuaFunction.

 

LuaTable and LuaFunction (and the associated LuaClosure) are the real heart on power of Lua. A table in Lua terms is a combination array and associative container (a hash table), its the only container that Lua has. LuaTable is the C# implementation of it, and can be used interfchangeable from C# or Lua.LuaFunction is even more exotic and powerful compared to functions in C#, in Lua functions are first class objects, can be created, manipulated and pass around like any other type. They can equally be functions from Lua or C#, its makes no difference and cos of the powerful closure system have upvalues support (upvalues and closure are a complex idea... essentially they are local stack variables which aren't on the stack, so have a different lifetime and survive with the function).

 

Because compiled lua files (called lil files from Lua Intermediate Language) are native CLR assemblies, they run directly on the .NET assembly. So inherit its garbage collector and debugging interface, however it rarely uses native types so will be nowehere as fast as native type CLR, however this isn't a problem for most uses of XNua and gives you the flexibity of a true dynamic weakly typed language (CLR was designed for static strongly typed language like C# and C++)