[[Call]] pass through result completion to callee

Brendan Eich brendan at mozilla.org
Tue Dec 4 12:49:08 PST 2012

Allen Wirfs-Brock wrote:
> On Dec 4, 2012, at 11:32 AM, Brendan Eich wrote:
>> In ES1-5 this was done in 13.2.1 [[Call]] on a function object. See also 13.2.2 [[Construct]], which layers on [[Call]], so [[Call]] is the lowest layer single algorithm that has to deal with completions.
>> Pushing down into FunctionBody is ok if there are no other uses of FunctionBody that do not want this common processing, i.e., where evaluation does not funnel through [[Call]]. Are there no other such uses?
>> ES1-5 all handle the cases via something like
>> 4. If result.type is throw then throw result.value.
>> 5. If result.type is return then return result.value.
>> 6. Otherwise result.type must be normal. Return undefined.
>> in 13.2.1 [[Call]].
>> Conserving this code under ES6's relocated [[Call]] internal method seems best, all else equal.
> I don't really think so. First we not have multiple implementations of [[Call]] (always could have, but it's now more obvious) and trap handlers implementing [[Call]] don't have direct access to Completion Records so they can't exactly emulate ordinary function [[Call]] does.

This is a good reason!

> Also, [[Call]] is mostly about defining with the invocation mechanism, not about the statement level semantics of a function body.  Determination of a function's result (including handling of internal returns and throws) seems like something that should be part of the specified semantics of a function body rather than of the [[Call]] MOP entry point.

It should be one of the two, but for ES1-5 it was [[Call]], which was 
*not* a MOP entry point. That change makes the good reason you gave above.

> As to the other point, nobody evaluates FunctionBody that doesn't want this semantics so it still is at one place and IMO the best place.

Good to know, thanks.


More information about the es-discuss mailing list