[[Call]] pass through result completion to callee

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Dec 4 12:00:18 PST 2012


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. 

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.

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.

Allen


> 
> /be
> 
> Yusuke Suzuki wrote:
>> Thanks.
>> 
>> I've just filed it to bugs.ecmascript.org <http://bugs.ecmascript.org> https://bugs.ecmascript.org/show_bug.cgi?id=1119
>> 
>>    It appears to me that the best fix is in the evaluation semantics
>>    of FunctionBody.
>> 
>> 
>> Looks nice to me too.
>> 
>> 
>> On Wed, Dec 5, 2012 at 3:15 AM, Allen Wirfs-Brock <allen at wirfs-brock.com <mailto:allen at wirfs-brock.com>> wrote:
>> 
>>    (Note that this is probably the sort of issue that would be better
>>    to report to bugs.ecmascript.org <http://bugs.ecmascript.org>)
>> 
>>    Yes, that looks like an issue.  It appears to me that the best fix
>>    is in the evaluation semantics of FunctionBody.  It should take
>>    care of Return completions and also make sure that normal
>>    completions yield undefined and not empty.
>> 
>>    Letting Return completions escape from functions was needed when
>>    we were considering supporting block lambdas but isn't need now.
>> 
>>    Allen
>> 
>> 
>> 
>> 
>> 
>>    On Dec 3, 2012, at 11:23 PM, Yusuke Suzuki wrote:
>> 
>>>    Hello all,
>>> 
>>>    Because of 8.3.19.1 step 17, [[Call]] returns result completion
>>>    even if result.type isn't return.
>>>    As the result, [[Call]] may return NormalCompletion(empty), is it
>>>    expected behavior?
>>>    I think we should change empty to undefined.
>>> 
>>>    For example,
>>> 
>>>    function test() {
>>>      var i;
>>>    }
>>>    var value = test();  // value is empty...
>>> 
>>>    --     Regards,
>>>    Yusuke Suzuki
>>> 
>>>    _______________________________________________
>>>    es-discuss mailing list
>>>    es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>>    https://mail.mozilla.org/listinfo/es-discuss
>> 
>> 
>> 
>> 
>> -- 
>> Regards,
>> Yusuke Suzuki
>> 
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 



More information about the es-discuss mailing list