[[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.

/be



More information about the es-discuss mailing list