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