> On Sep 29, 2014, at 7:55 AM, John Lenz <[email protected]> wrote: > > > > On Sat, Sep 27, 2014 at 10:53 PM, Filip Pizlo <[email protected] > <mailto:[email protected]>> wrote: > I would also like to see this standardized. Comments inline. > > > On Sep 27, 2014, at 10:15 PM, John Lenz <[email protected] > > <mailto:[email protected]>> wrote: > > > > I would like to get see stack traces standardized for ES7, to that end, I > > would like to define a minimal set of behaviors that would need to be > > defined: > > > > * the "stack" property (a string) > > * when the stack property is attached (at Error object creation or at throw) > > * what happens when Error object that has been thrown, is thrown again > > (nothing) > > * the stack trace in the face of tail recursion optimizations (skipped?) > > Is that really necessary? If so, can you say something about the motivation? > > You can do some tail recursion optimizations while preserving the stack > trace. For example if you call yourself recursively and the JIT turns it into > a loop, then all you need is the loop trip count to recover the original > stack trace. > > I really have no idea what the behavior should be in the faces of optimized > tail calls (which is must broader than simply self recursive methods that can > be rewritten as a loop). I've seen various suggestions (a capped call > history) but I'm curious how efficient functional languages deal with this.
The last time I used ML, which was admittedly a long time ago, the two main implementations (MLton and SML/NJ) simply didn’t have stack traces. > > I haven't actually seen anything about tail recursion optimizations being > implemented, have any of the VM actually tried or committed to implementing > tail call optimizations? We (JSC) haven’t. And we don’t plan to, because: - We still need to be able to reconstruct the original stack for things like function.caller and function.arguments. We are trying to remove the latter but the former still lives. - Debugging. Our inspector UI promises stack traces for breakpoints and whenever exceptions are thrown. We could make tail call optimizations work only when the inspector is not attached, but this would be weird. Tail call optimizations end up being a kind of semantic guarantee, since if they work you can write loops using tail calls. It would be weird if attaching the inspector suddenly made all of your tail calls turn into stack overflows. It’s actually better if the risk of stack overflow is equal regardless of whether the inspector is attached. - JS is a great language; it actually lets you write an honest loop. You don’t *need* tail calls. -Filip > > > > * the minimal information that a stack trace should contain (file, line, > > column) > > * the format of the minimal information > > * how additional information is added to the stack trace (named evals, etc) > > > > Does this sound like a reasonable minimal set? > > +1 > > > > > _______________________________________________ > > es-discuss mailing list > > [email protected] <mailto:[email protected]> > > https://mail.mozilla.org/listinfo/es-discuss > > <https://mail.mozilla.org/listinfo/es-discuss>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
