Jeff Clites <[EMAIL PROTECTED]> wrote: > On Nov 11, 2004, at 9:44 AM, Michael Walter wrote:
>> On Thu, 11 Nov 2004 12:30:16 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: >>> Tail calls should be explicit, compile-time things. > Nah, that's just the difference between running optimized and > unoptimized. Actually, with a tailcall op that's effectively a hint, No. It's an opcode doing tailcalls. The optimization is coming from the language. In case of imcc it's turned on with -Oc (optimize calls) currently. And when the language compiler emits a tailcall sequence, however that construct might look like, then it'll be translated as one. > I think that actually doesn't matter. Even in the case where we think > we can't do a full tail call optimization (because of a continuation > that's been taken), we can still actually remove the calling frame from > the call stack--we just can't immediately re-use the register frame. As Dan already has outlined a Continuation doesn't have any impact on tail calls (my argument WRT that was wrong) A tail call just uses the current continuation of sub A and passes it on to the called sub B, so that the called sub B returns to the caller of A. > Leo said: >> $ time parrot -j fact.imc 10000 # [1] >> maximum recursion depth exceeded > I'd think that long-term our max recursion depth limit should only > apply to net frame depth Above is *without* tail calls. The next one was with tail calls, and it obviously did succeed, because tail calls do not contribute to any kind of stack depth. So there is for sure no limit. It's the same as an iteration loop for the recursive tail call case - no limits. > JEff leo
