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