Maximally minimal stack trace standardization

Allen Wirfs-Brock 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 19.2.3.3 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
> Function.prototype.call"?
> 
> 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.

Allen


More information about the es-discuss mailing list