Maximally minimal stack trace standardization

John Lenz concavelenz at gmail.com
Mon Sep 29 07:55:30 PDT 2014


On Sat, Sep 27, 2014 at 10:53 PM, Filip Pizlo <fpizlo at apple.com> wrote:

> I would also like to see this standardized. Comments inline.
>
> > On Sep 27, 2014, at 10:15 PM, John Lenz <concavelenz at gmail.com> 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.


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?


>
> > * 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
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140929/b86b3737/attachment-0001.html>


More information about the es-discuss mailing list