Maximally minimal stack trace standardization
Mark S. Miller
erights at google.com
Mon Sep 29 13:13:17 PDT 2014
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
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
On Mon, Sep 29, 2014 at 1:02 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
> 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).
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss