Maximally minimal stack trace standardization

Sam Tobin-Hochstadt samth at cs.indiana.edu
Mon Sep 29 13:16:28 PDT 2014


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
>


More information about the es-discuss mailing list