proper tail calls

Thomas Reilly treilly at
Tue Jan 22 12:31:39 PST 2008

> Tail call != recursion. Not even indirect recursion. The 
> point is you may see gaps in the stack where control seems to 
> flow from f to g, but nothing in tail position in f could 
> possibly call g, and you wonder what might have intervened.

My bad, thinking about the scheme looping special case.  Anyways the
point remains that just because the implementation was clever and
optimized away f's frame, or reused it or whatever doesn't mean a
debugger can't remember it and show it as either still being there or as
being ghosted out or something.  I think the feature is too valuable to
rule it out b/c it places constraints on the debugger.  And I wouldn't
want any constraints to be levied by the language/spec.  I would even
think it reasonable for implementation to have a policy where you had to
turn the VM into interpreter mode to get the whole picture.

To back up my point about this feature being important I'll bring up
Flex and code generation.   A Flex application has this nesting notion
where the XML nesting of your Flex components is translated into a chunk
of nesting AS3 code for initialization purposes.  Thus as its
implemented your Flex component nesting is bounded by your available
stack space.  The ease at which MXML facilitates component nesting means
that some day we'll either have to change this to initialize using an
explicit heap data structure but maybe if explicit tail call support
existed they could keep using it and feel safe to keep on doing it this
way.  Basically its automatic vs manual memory management and a
scripting language shouldn't force people to do manual memory

My vote is to have an explicit syntax with the optional implicit allowed
(encouraged?) caveat. 

More information about the Es4-discuss mailing list