On Mon, Sep 29, 2014 at 4:13 PM, Mark S. Miller <[email protected]> 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 <[email protected]>
> 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
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
