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