> 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 management. My vote is to have an explicit syntax with the optional implicit allowed (encouraged?) caveat. _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
