Maximally minimal stack trace standardization
allen at wirfs-brock.com
Mon Sep 29 14:06:46 PDT 2014
On Sep 29, 2014, at 1:41 PM, Jason Orendorff wrote:
> On Mon, Sep 29, 2014 at 3:02 PM, Allen Wirfs-Brock
> <allen at wirfs-brock.com> wrote:
>> 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.
> Function.prototype.apply, Function.prototype.call, and Reflect.apply
> currently call PrepareForTailCall. Is this a bug?
No, I don't believe so. Built-ins (whether implemented in ES or native) are specified to have an "execution context". The PrepareForTailCall release that execution context for before performing a [[Call]]. It's working in the above functions just like it works from any other call site.
In other words, the spec. language says that these buil;t-ins functions explicitly end with an ECMAScript tail call.
> I can see that the current language in 14.6.3 PrepareForTailCall only
> covers "tail position calls" and "resources associated with the
> currently executing function execution context", but what's wrong with
> copying that sentence into 184.108.40.206 and changing it to refer to "the
> internal method call in the last step of the above algorithm" and
> "resources associated with the current call to
> The spec constrains the behavior of builtins in all kinds of ways,
> regardless of what language they're written in. I don't understand
> what is special about stack space usage that makes it off-limits.
I'm not sure what would be the point of duplicating the language. Since those functions use PrepareForTailCall, what is says applies to them.
More information about the es-discuss