On 16.05.2011 0:37, Brendan Eich wrote:
On May 15, 2011, at 11:55 AM, Dmitry A. Soshnikov wrote:
Oh, my misunderstanding then. Then I just incorrectly treated yours
assert(p === q);
This was from
// Use # to freeze and join to nearest relevant closure
function return_pure() {
return #(a) -> a * a;
}
let p = return_pure(),
q = return_pure();
assert(p === q);
and the assertion means what it seems: p is identical to q.
I though here you try to show that the engine will handle the case with
optimization and reuse (i.e. to join) the function object.
I'm not talking about optimization -- this is a case where joining works, since
the function is pure. It closes over no outer variables' locations.
However, it still not possible because of different scope chain, that exactly
why I was asking.
No, that's not what the strawman says, and not what I said last time. The issue
is not different scope chains, it is whether there are captured closure
variables whose abstract locations are not invariant with respect to the source
function expression in question.
Each evaluation of a given function expression gives a fresh object in JS
today. WIth joining as Mark proposed at
http://wiki.ecmascript.org/doku.php?id=strawman:const_functions#joining
Got it. Though it still seems to me as just an implementation
optimization without need to specify explicitly that a function is
closed (without free variables) and thus can be optimized, i.e. created
once and stored as some internal property.
Dmitry.
and with opt-in syntax (the # prefix) as I'm proposing, this "fresh function object
for each evaluation of a function expression" rule would no lot apply.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
