Practically speaking, I agree. On Mon, 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 > > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
