RE: Lua 5.0 Alpha and api_incr_top

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

>I think there is a misunderstanding here. The Lua 5.0 stack grows
>automatically on demand during recursive calls (unlike Lua 4.0,
>where the stack was fixed), and there is a "polite" error in case
>of stack overflow. What does not grow automatically is the virtual
>stack that each C function sees.

I am referring to anything in the Lua 4.1 series.

I have no problem with a stack that grows.  In fact, I would say that
would be expected behavior.  I saw cases previous to Lua 4.1 Alpha where
the stack ran out, and in an embedded environment, that isn't a good
thing (or can be a good thing, depending on how you look at it).

I expect that calling an API that requires stack manipulation would
ensure the stack was the right size before the manipulation.  In the Lua
4.1 series, this was the case, and I didn't have to worry about Lua
"randomly" memory overwriting data.

>Usually this virtual stack is for temporary values only (function
>parameters, function results, and "local" variables). For most C
>functions it is quite easy to know in advance how much stack you
>will need. Very few tasks demand that you keep pushing new values
>on the stack without removing them. For these few tasks, you need
>to call lua_checkstack (or more easily luaL_check_stack). See
>luaB_unpack (in lbaselib.c) for an example.

This presumes that people operate with Lua in a prescribed way.  My
situation does not fit this.  Instead, it works with intertwined data,
some of which is left on the stack for extended periods of time.  When
the process is finished, the stack is, of course, clean, but it can
require, depending on size of data, hundreds or thousands of stack
entries (big databases).

You might say I am doing this incorrectly, but I am doing this very
efficiently, because stack access is lightning fast, whereas
lua_getref() access time has increased considerably since the Lua 4.0
series.

I still don't understand the behavior.  Lua's stack grow should be just
as invisible in C as it is in Lua.  I mean, why not?  It makes the C API
way easier to use for individuals.  The stack based API is already
difficult to train people to use correctly (which is why I have a C++
wrapper object around it).  Making them know just how much stack space
they need really makes their life difficult.

I use Lua as a replacement for what might be XML data.  Lua's data
representation capabilities are, in my opinion, far better than XML's.
Adding one more conditional to C usage does not help the ease of use of
the C API (lua_checkstack).

So, why not make it easier for the end user?  Why should they have to
write code that checks the size of the stack before every function call?
That's better embedded in the internals of Lua, IMHO.  Otherwise,
there's too much of a chance the use of the Lua API will compromise the
integrity of the system because the programmer "forgot" to put a
lua_checkstack() in.  By putting the check in the API, the programmer
can be confident that Lua won't crash or overwrite memory, since Lua
always ensures it has enough memory to perform the task it needs.

Thanks,
Josh