Re: Addition of map() and filter().

[Eike Decker <zet23t@...>]

2009/10/14 TNHarris <telliamed@whoopdedo.org>:
> On Mon, 12 Oct 2009 23:16:12 +0200
> André Ericsson <eandre@gmail.com> 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
> telliamed@whoopdedo.org
>

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.

Eike