Maximally minimal stack trace standardization

Mark S. Miller erights at google.com
Mon Sep 29 13:18:58 PDT 2014


Practically speaking, I agree.

On Mon, Sep 29, 2014 at 1:16 PM, Sam Tobin-Hochstadt <samth at cs.indiana.edu>
wrote:

> On Mon, Sep 29, 2014 at 4:13 PM, Mark S. Miller <erights at google.com>
> wrote:
> > The issue is the asymptotic space consumption almost-contract. The
> reason I
> > say "almost" is that conformance of an implementation is not testable.
> > Currently, the spec says nothing about when an implementation might run
> out
> > of storage.
> >
> > So we (at least I) mean normative only in the following sense: When
> someone
> > writes an algorithm in ES6 using, say, bound functions in a loop, what
> > claims may they validly make about the space complexity of their program?
> > The specification should help answer such questions, sometimes.
> >
> > Note that I distinguish here between "the space complexity of their
> program"
> > and the space usage growth when their program is run on an actual
> > implementation. Again, conformance with any requirement on the latter is
> not
> > testable.
>
> I think we can make it testable.
>
> We'd consider it a spec violation (at least, I would), if this program
> ran out of space, ever:
>
>     var i = 0;
>     while (1) {  i++; };
>
> similarly, this program should never run out of space:
>
>     var i = 0;
>     function f() { i++; return f(); }
>     f();
>
> If we write a test that checks counting to a specified number, I think
> test262 can adequately test this behavior.
>
> Sam
>
>
> >
> >
> > On Mon, Sep 29, 2014 at 1:02 PM, Allen Wirfs-Brock <
> allen at wirfs-brock.com>
> > wrote:
> >>
> >>
> >> On Sep 29, 2014, at 12:02 PM, Brendan Eich wrote:
> >>
> >> Allen Wirfs-Brock wrote:
> >>
> >> No particular reason an implementation can't optimize through that if
> they
> >> want to.
> >>
> >>
> >> The question is whether it should be normative. PTC is about observable
> >> asymptotic space performance (I keep saying :-P).
> >>
> >> /be
> >>
> >>
> >>
> >> What should be normative?  You guys probably should probably review the
> >> actual spec. language and see if you have any issues with it.  All the
> tail
> >> call action takes place in the spec. on the caller side. See
> >>
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-evaluatecall
> >> and
> >>
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-preparefortailcall
> >>
> >> The resources requirements of a function are represented by its
> "execution
> >> context".  PrepareForTailCall says the the caller's "execution context"
> is
> >> discarded before invoking the callee's [[call]] internal method.
> [[Call]]
> >> for bound functions does not create a new "execution context" so there
> is no
> >> associated specified resource consumption that needs to be optimized
> away.
> >> At least as far as the spec. is concerned, bound functions (whether
> strict
> >> or sloppy) have no impact on TCO.
> >>
> >> I can't imagine what you would want be to try to say about
> non-EMCAScript
> >> functions. Their internal "call" semantics is determined by the
> semantics of
> >> their implementation language.
> >>
> >> Allen
> >>
> >>
> >
> >
> >
> > --
> >     Cheers,
> >     --MarkM
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140929/5e813f34/attachment-0001.html>


More information about the es-discuss mailing list