Maximally minimal stack trace standardization

Filip Pizlo fpizlo at apple.com
Mon Sep 29 13:19:07 PDT 2014


Another way to make this (somewhat) testable is to require specific error.stack behavior for TCO.  For example, a call in tail position may require that the caller does not show up in the stack trace.

-Filip


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


More information about the es-discuss mailing list