lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Wed, Oct 14, 2009 at 1:25 PM, Eike Decker <> wrote:
2009/10/14 TNHarris <>:
> On Mon, 12 Oct 2009 23:16:12 +0200
> André Ericsson <> wrote:
>> local LOCAL_ToStringAllTemp = {};
>> function tostringall(...)
>> -- etc...
> That's rather ugly.
> I've learned that recursion isn't a dirty word in Lua, so it's not at
> all difficult to write a 'map' function
>    function map(f,...)
>      if select('#',...) == 0 then return end
>      return f((...)),map(f,select(2,...))
>    end
> Which could be optimized to use local variables only. However, that does
> demonstrate one thing about Lua that I didn't expect. This...
>    return something, F()
> ... isn't a tail-call. I thought it would be, but the comma operator is
> enough to prevent the optimization. I think it would be a worthwhile
> change to the VM to allow a tail-call in this case.
> A function that I think is better done in C than Lua is a
> complement to 'select', which could be called 'shift'.
> shift(n,...) returns the values that select(n+1,...) skips over.
> -- tom

Tail calls don't change the stack's size, thus preventing the stack
from overflowing. If you would however keep the stack increasing just
the way how your code intends to, what would be the benefit of
optimizing this (rare) case? I mean, sooner or later, a stack overflow
could then happen as well.


For buggy code, yes, this would mean that tail recursion could overflow the stack.

For proper code it wouldn't be a problem. While you'd increase the stack offset by one to insert your prepended value, you'd also remove that same value from the varargs in the stack, so you'd end up with a constant stack size.