proper tail calls

Thomas Reilly treilly at
Tue Jan 22 11:27:36 PST 2008

Depends on what you mean by meaningful stack trace.  Do you actually
want to see the same function name repeated N times for each invocation?
I would think not, I would just come up with some notation to decorate
the stack trace.

Its probably important to go back to Brendan's point about this being a
feature and not an optimization.  Even in Java the stack traces you get
are very distantly related to the actual code running when all the
inlining, escape analysis, and traditional optimizations are applied.
They jump through a lot of hoops to give you that valuable stack trace
in spite of all those optimizations and ES4 implementation will have to
do the same.  As a language feature and not just an optimization it
makes sense to have a notation for stack traces even if that's an
implementation detail.   Maybe we could even have something in the
non-normative part of the spec or just agree to follow the RI's lead and
have it do something agreeable.

> -----Original Message-----
> From: es4-discuss-bounces at 
> [mailto:es4-discuss-bounces at] On Behalf Of Neil Mix
> Sent: Tuesday, January 22, 2008 11:03 AM
> To: Dave Herman
> Cc: Peter Hall; Brendan Eich; es4-discuss at; Jeff 
> Dyer; Erik Arvidsson
> Subject: Re: proper tail calls
> Not sure if this was clear, but I'm not arguing against PTC 
> altogether, just *implicit* PTC.  I have no qualms about 
> explicit PTC.  (I'm even fairly sympathetic to arguments for 
> implicit PTC, I'm just worried -- based on Brendan's 
> statements -- that debugability isn't getting the weight it deserves.)
> I also want to make clear: this isn't about debugging code 
> that uses PTC intentionally -- that tradeoff is up to the 
> developer.  This is about the novice coder who finds a stack 
> trace on a production system from code that he doesn't own 
> which just happens to be invoking PTC implicitly.  Say what 
> you will about Java (I've probably said worse), but stack 
> traces in production logs are a godsend for problem solving.  
> Implicit PTC concerns me for that reason -- how do you "turn 
> off" an implicit language feature?  How do you craft a coding 
> standard to avoid implicit PTC?
> That said, if meaningful stack traces can be generated in 
> spite of implicit PTC (you and Thomas Reilly mentioned 
> debuggers, I wasn't so clear on traces), I'll happily scurry 
> back into my little corner and shush.  ;)
> On Jan 22, 2008, at 11:07 AM, Dave Herman wrote:
> > Neil,
> >
> > I understand your points. But I wouldn't want to defeat an 
> important 
> > feature simply because novices wouldn't understand how to use it. 
> > Especially in this case, where it should be possible for 
> the feature 
> > to coexist with novices without them tripping over it.
> >
> > People's primary concern with "tripping over tail calls" 
> appears to be 
> > with debugging. You say Brendan's debugger wish list is on 
> steroids, 
> > but creating a debugger that is compatible with tail calls doesn't 
> > have to be a dramatic engineering challenge. One approach some 
> > debuggers (I believe recent builds of SML/NJ do this) is for the 
> > debugger to hang on to some bounded queue of the most recent tail 
> > calls (this is applicable to loop iterations if that would 
> be useful 
> > too). That way it's still only consuming a constant amount 
> of space, 
> > but a stack trace or checkpoint could see the recent 
> "trail" of tail 
> > calls. This isn't hard to implement.
> >
> > Dave
> >
> > Neil Mix wrote:
> >>>> Thanks. That would work. But I can still see the "average" user 
> >>>> being confused when debugging, and not knowing what is going on.
> >>> Would you think an explicit keyword syntax for mandatory 
> tail call 
> >>> would help such a user?
> >> I do.
> >>> To the claim that debugging in the face of PTCs will 
> become madness- 
> >>> inducing, Schemers and others retort "do you want to see 
> every state 
> >>> of an iteration?" (A loop is a tail call in Scheme.) The right 
> >>> answer is "yes". Yes, I want a debugger that remembers 
> all program 
> >>> states
> >>> ( and runs in near 
> real-time 
> >>> (not chronomancer, alas -- not yet). I want the moon, as 
> a debugger 
> >>> user (and yet I still suffer in this day and age with gdb!).
> >>>
> >>> My point is that debugging is a specialized task with immature 
> >>> (frozen in the last days of disco!) tools; the debugger 
> tail should 
> >>> not wag the dog.
> >> I can't argue the sentiment.  But exactly how soon will 
> such advanced  
> >> debugging tools be generally available and in the hands of the  
> >> programmers we're discussing?  Before ES4 has given way to ES5/6/7?
> >>> Separately, poring over crashdumps (which is not the same as 
> >>> debugging, and not a task for "average" users), many C++ hackers 
> >>> have had to deal with good old "TCO". It's a pain, but we 
> keep the 
> >>> optimization levels high for production builds and suffer the
> >>> entrail-
> >>> reading horror when investigating crashes.
> >> Without forcing you to declare your age ;) I must point 
> out that it's  
> >> common these days for programmers to have over a decade's 
> experience  
> >> without any coredump debugging experience.  (I'm
> >> *almost* an example  of this.)  I'm having a hard time 
> swallowing the 
> >> argument that it's  OK for a modern language like ES4 to 
> require the 
> >> skillsets used for  assembly++.  (I'm not arguing that 
> those aren't 
> >> good skillsets to  have, just pointing out the reality of 
> >> next-generation programmers.)
> >>> I've heard Schemers testify that tail calls seldom impair 
> debugging, 
> >>> but I'll invite those Schemer among the many on this list 
> who are so 
> >>> inclined to re-testify.
> >> I think that's skewing the sample.  We're not talking 
> about schemers  
> >> here, we're talking about scripters.  They don't read 
> language specs,  
> >> they use tutorials and references, and they just so happen 
> to vastly  
> >> outnumber the people on this list.  Advanced PLT concepts 
> are "over  
> >> engineered" from their perspective.  They have no frame of 
> reference  
> >> for incomplete stack traces.  Implicit PTC will confuse 
> the heck out  
> >> of them, they'll go straight to bugzilla and file a bug on the  
> >> interpreter.  ;)  At least
> >> Explicit gives them a fighting chance.   They might just ask,  
> >> "what the heck does that keyword mean, anyway?"  and go 
> look it up in 
> >> their favorite reference.
> >> I think the implicit-hurts-debugability argument has a lot more   
> >> weight than you're giving it, especially in the near-term.
> >> _______________________________________________
> >> Es4-discuss mailing list
> >> Es4-discuss at
> >>
> >
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at

More information about the Es4-discuss mailing list