Re: Latent functions

["Thatcher Ulrich" <tu@...>]

On Dec 03, 2001 at 11:06 -0500, Jay Carlson wrote:
> 
> Why do you need to remove OP_TAILCALL?

I probably don't... I was worried about it because Bret's roadmap
email mentioned not grokking OP_TAILCALL right away, but looking at it
now it doesn't look scary.

> Also, C code that wants to call back into Lua will have to play nice with
> this scheme.  Instead of executing lua_call, it will need to push the
> function and args on the stack and *return* to the bytecode engine, and let
> the engine do the call.

I'm about knee deep in this right now.  So far I've added a
"lua_resume(lua_State* L)" call, which picks up right after where the
Lua script called "sleep()" (a new function in baselib).  The lua_do*
functions can return a new code, LUA_SLEEP, to indicate that the
script exited by calling "sleep()", and the lua_State is
lua_resume()-able.  lua_resume() will throw a lua_error() if you call
it improperly.

On Dec 03, 2001 at 02:01 -0600, Roberto Ierusalimschy wrote:
>
> It is important to remember that the recursive call in luaV_execute
> happens not only via OP_CALL. All tag methods may result in luaV_execute
> calling itself, and this may happen in several opcodes (OP_GETTABLE,
> OP_SETTABLE, OP_ADD, etc.).

Right... I'm not going to try to make those non-recursive, at least
not yet.  What I'm doing so far is keeping a recursion count (per Bret
M), so that if a script calls "sleep()" from within a recursive
luaV_execute, it will generate a message and just continue; i.e. *not*
try to sleep.  Bret indicated that this worked well enough for his
purposes, and it sounds like it'll be fine for me and others as well.
We'll see.

-- 
Thatcher Ulrich <tu@tulrich.com>
http://tulrich.com