proper tail calls

Dave Herman dherman at ccs.neu.edu
Tue Jan 22 09:07:35 PST 2008


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
>> (http://code.google.com/p/chronomancer/) 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 mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss




More information about the Es4-discuss mailing list