3 ms·

However the stack space is ‘recycled’ such that if you have a tail recursive algorithm, the first tail call that isn’t ‘easy’ will erect the TailCallHelper stac

However the stack space is ‘recycled’ such that if you have a tail recursive algorithm, the first tail call that isn’t ‘easy’ will erect the TailCallHelper stack frame, and subsequent non-easy tail calls may need to grow that frame to accommodate all the arguments. Hopefully once the algorithm has gone through a full cycle of recursion the TailCallHelper stack frame has grown to the maximum sized needed by all the non-easy calls involved in the recursion, and then never grows, and thus prevents a stack overflow. - does this mean that it's possible to use TailCallHelper but still not be able to guarantee no stack overflow?

amock 17y ago
Yes, but I don't think that's more true of TailCallHelper than of any function calls using a stack. This sounds like it's saying that even with tail call optimization it's possible for the arguments to a function to be too big for the stack. For example, if the arguments you pass to the recursive function call are stack allocated and grow each time then each call will increase stack usage, even though it's reusing the space from the previous call.
mquander 17y ago
It sounds to me like the stack space required by TailCallHelper is proportional to the largest amount of stack space ever consumed by a single call of the tail recursive function(s) it's assisting, whereas without it, the stack space required would be proportional to the depth of recursive nesting. So using TailCallHelper you should be able to guarantee arbitrarily deep tail recursion.
bad_user 17y ago
It seems to me that the TailCallHelper is just a trampoline ... the method wanting to do a tail call places on the stack a reference to the next method to be called + it's arguments, returns, and then TailCallHelper calls it. So yeah ... you have a guarantee, but it's also using stack space, so you have to watch-out for big arguments lists, because that may overflow the stack.

amock 17y ago

Yes, but I don't think that's more true of TailCallHelper than of any function calls using a stack. This sounds like it's saying that even with tail call optimization it's possible for the arguments to a function to be too big for the stack. For example, if the arguments you pass to the recursive function call are stack allocated and grow each time then each call will increase stack usage, even though it's reusing the space from the previous call.

mquander 17y ago

It sounds to me like the stack space required by TailCallHelper is proportional to the largest amount of stack space ever consumed by a single call of the tail recursive function(s) it's assisting, whereas without it, the stack space required would be proportional to the depth of recursive nesting. So using TailCallHelper you should be able to guarantee arbitrarily deep tail recursion.

bad_user 17y ago

It seems to me that the TailCallHelper is just a trampoline ... the method wanting to do a tail call places on the stack a reference to the next method to be called + it's arguments, returns, and then TailCallHelper calls it. So yeah ... you have a guarantee, but it's also using stack space, so you have to watch-out for big arguments lists, because that may overflow the stack.