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 <[email protected] >> <mailto:[email protected]>> 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 >>> [email protected] <mailto:[email protected]> >>> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> >> -- >> Regards, >> Yusuke Suzuki >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
