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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
