Re: Tailcalls. Was Re: Manual timeslicing the VM.
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Tailcalls. Was Re: Manual timeslicing the VM.
- From: Rici Lake <lua@...>
- Date: Fri, 5 Aug 2005 13:06:40 -0500
On 5-Aug-05, at 12:53 PM, Glenn Maynard wrote:
Here, I was referring to self-recursion: it may make sense, when
debugging,
to want to know which function kicked off a tight recursion, but in the
state machine case it feels wrong and unintuitive for a debugging
function
being asked "who called this function" to return the function that
started
the state machine originally.
Does it? Would you want the debugging function to show you the 327,432
previous states before you saw the function that originally created the
maze? Would you want the state machine to fail because of stack
overflow?
gcc can be instructed to not insert tailcalls; under some circumstances
this is useful, although as the maze example illustrates it can lead to
other bugs. Still, for those occasions, and for those who share your
intuitions about state machines, it might be reasonable to have some
mechanism in Lua for doing the same thing; the nontailcallable closure
flag I suggested has the advantage of allowing some selectivity.
(Suppose you use a library which unbeknownst to you is implemented with
a tailcalled state machine; globally turning tail calls off might then
make it impossible to debug your code because the library consistently
crashes.)
Yet another possibility would be preprocessing the compiled Lua byte
code, replacing every instance of OP_TAILCALL with OP_CALL. This is
safe, because the compiler cannot know whether or not the function
being tailcalled is a Lua function or a C function, so it always emits
an OP_RETURN after an OP_TAILCALL.