RE: Lua 5.0 Alpha and api_incr_top

["Joshua Jensen" <jjensen@...>]

> You could use a single table to keep your data, using integer 
> indices (like you do with the stack), and using the functions 
> lua_rawgeti and lua_rawseti. If your table is an "array" 
> (which it will be), these functions are very very fast. (They 
> will not do any table lookup, only an array access.)

I could do this, but I've always promoted Lua as a better alternative to
XML.  Freeform your data.  Change it at will.  Make sweeping
updates/rearrangements with a few lines of script.  Consistent API per
platform, as opposed to having to find an XML library per platform.

That said, I certainly wouldn't want to tell other Lua users: "Lua will
let you freeform your data, but don't do that if you're going to access
the data from C (usually one time).  Otherwise, you'll have to train
your developers on the complexities of Lua stack management and just
what functions require usage of the stack."

> About the stack: in the old days, the C stack grew 
> automatically. The problem was, it is very common error the 
> unbalanced use of the stack (e.g. loops that do not clear up 
> the stack properly). With a dinamic stack, those errors were 
> seldom caught; instead, they resulted in an ever-growing 
> stack, with program resources disappearing without apparent 
> cause. So, we followed the "make your program crash earlier" 
> principle.

I agree on the dynamic stack point.  Because of one data set, I had one
developer with a stack >1000 entries.  Most of it was mismanagement of
the stack and in the end, we got the usage down to 100-ish entries.  He
didn't understand stack management and why he had to care about it to
access his data from C.  I agree with his point, and I have done
everything in my power to mask the stack management from other users
(through a wrapper, of course).  Even so, his stack still grew to >1000
entries.

I understand your position.  You're not interested in automatically
growing the stack.  That low-level responsibility should reside on the
API user's head.  While I disagree, I'm not going to create a flame war
here.  If possible, at least "#define api_check assert" by default,
because it will at least flag an error when the problem happens, rather
than having the application crash (which is a very bad thing, of
course).  Also, in the reference manual or lua.h, comments about how
many stack entries a function requires for both input/output would be
useful.

Lastly, I see Lua as an alternative for XML, as I said.  I haven't seen
an XML API implementation that requires the user to learn about a stack.
If the user wants to use Lua entirely for data description, he/she
should be able to do so without having to worry about such an issue.
This greatly enhances Lua's value and ease of use.

Josh