> On Sep 29, 2014, at 1:26 PM, Sam Tobin-Hochstadt <[email protected]> wrote: > > I think this would be a mistake -- as I mentioned, there are a number > of possible strategies for stack traces w/ proper tail calls,
But we should spec one of them, particularly if we want to move towards returning the stack trace as structured data. I think it would be good for implementations to be consistent and for the stack trace to not vary depending on which optimization tier you ended up in. > and as > Steve Fink mentioned, these also arise when considering inlining and > other optimizations. Nope. Inlining and other optimization a don't typically wreak the havoc on stack traces that TCO does. > We shouldn't prevent implementations from trying > to experiment with what works best here. Is there something concrete that it would prevent anyone from trying? > > Sam > >> On Mon, Sep 29, 2014 at 4:19 PM, Filip Pizlo <[email protected]> wrote: >> 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]> 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 >> >> _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
