arrow syntax unnecessary and the idea that "function" is too long

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Sun May 15 13:52:15 PDT 2011


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
>



More information about the es-discuss mailing list