Re: Some questions on Lua's design

[Tim Hill <drtimhill@...>]

> I've read that a Lua program IS a table. This would suggest that it would be trivially simple to save the state of a lua program or subroutine by writing out said table- which has a lot of intrinsically awesome properties if my assumption is correct. How does this work, conceptually, in relation to the program as a running procedure? Are we just iterating through a table of expressions or is there a special way in which we are stepping through the program? It seems like we're stepping through a table of expressions and throwing things onto a stack until we have an evaluation which may or may not bubble up in scope to modify values of some other tables. Is it as LISP-like as it seems?

No, Lua programs are not tables. However, functions (the unit of code in Lua) ARE first-class values, which means you can treat a function in the same way you would treat (say) a number or string.

> It seems like all data is or could be perfectly well-managed. Why is there a need for a GC? When we leave scope all local variables get freed and whenever a table is nil'ed we're implicitly freeing that memory. I don't understand GC's very well-- in C, we malloc and free memory whenever we need to.

Lua needs a GC to automate memory management. Memory is allocated when necessary, however it turns out to be rather more complex to know when memory can be freed (automatically). Humans get it wrong all the time; hence the ubiquity of pointer problems in C and C++. The GC gets it right, but its not as trivial as you make it seem, mostly because of circular cross-references. Local variables (or, to me more precise, the value they reference), are NOT necessarily freed when they exit scope, as a result of upvalues. Similarly, A table can be referred to via many different variables (global and local, as well as upvalues).  Determining when a value is truly unused (in GC terms, "unreachable"), is non-trivial and is the task of the GC.

> This leads me to another point of conjecture in regards to memory management. This is more of a general question about language design. How are static values stored in memory? Suppose I have an expression,
> X = 10
> In C, we have a zillion different integer types to wrap memory allocation expectations into the definition. That all makes sense, but in the above expression, we don't need more than 4-bits. In C, we can malloc 4 bits of space, assign it to a variable, and just treat it like an integer- afaik, the type declarations in plain old C are not much more than syntactic sugar. However, suppose we have-
> X, Y = 10, 10
> Y = X + Y
> X and Y, in my mind, should both initially point to the static value 4-bit value of 10. Then they're put on an evaluation stack, the result is cached, and then Y points to a new static 5-bit value of 20. Now let's do,
> X = 4

Lua is a high-level language and hence abstracts (mostly) things like numeric representation (this is also true, though less so, of C). Essentially the philosophy of Lua is "don't worry about the internal details", because that's the job of the language and the VM. Of course, this makes Lua do rather more work behind the scenes that (say) C, which is one reason why Lua will never be as fast as C. However, *no* language will do the kind of thing you are proposing, since the language must map to the underlying CPU architecture, and in general these are designed to work optimally on numeric values of certain sizes (for example, 32 or 64 bit integers).

> It seems like all data in Lua are tables. That there aren't actually any simple data types- but rather syntactic sugar to make them feel simple. IE a number "Type" is cloned or generated from an expression that outlines the metatable necessary for a number to function in the way we expect. Is this how Lua does it? If it is, very cool- I can see how that would streamline the engineering side of the language. Do all of Lua's primitives function in this manner? Or am I just completely off on this assertion? With the above memory concerns, it seems like Lua could easily manage memory without a GC, implicitly calling malloc/free in appropriate places- or is this what it is essentially doing?

No, Lua DOES use tables as the only AGGREGATE type, but things like strings and numbers are not tables. Metatables are just a way to attach user-defined behaviors to certain Lua operations on values on certain types. As noted above, the GC *IS* the part of Lua that automatically manages memory. You seem to be saying, "we don't need a GC because Lua should detect when memory can be freed and release it automatically". But that's what the GC *is* .. the bit of the Lua that detects when memory can be freed and does it.


--Tim