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

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Mon May 16 01:28:02 PDT 2011


On 16.05.2011 1:47, Brendan Eich wrote:
> On May 15, 2011, at 1:54 PM, Dmitry A. Soshnikov wrote:
>
>>> See last reply for more on joining. It occurs to me you thought scope chain varying in the context of a pure hash-rocket such as #->42 means that function cannot be joined, but since it is pure, it need not entrain its scope chain as an internal [[Scope]] property.
>>>
>>> More, since # freezes, there's no need for it to be duplicated, since there is no mutation side channel.
>>>
>>> So http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax proposes freezing and joining, only if the user specifies via the # prefix.
>> Yep, I got it, thanks, though, as mentioned seems it can be managed then at engine level without explicit specifying by the user, no?
> Do you mean that users shouldn't have to write # prefixes to get joining?

Yeah

>   That is hard.

Yes, I assumed it though. So from this viewpoint #-funcitons (and 
actually #-symbol) is just an addition, perhaps even won't be used 
actively by users. Because I can imagine some tutorials explaining it 
"don't forget to put # to make a frozen function in case your function 
is closed over and doesn't contain free variables". It's OK, though I 
think that before reminding do not forget # in such cases, it will be 
needed to explain to novice what is a free variable, what is closure, 
etc. So probably #-functions will not be wide-spread. Although... But, 
it's just thoughts.

Since semantics of # is moved in respect of function, maybe we can it 
nevertheless use for records/tuples and for meta-properties of 
initialiser (Allen's proposal, don't remember why this topic has became 
silent)?

#record = {x: 10, y: 20}; // without proto
#tuple = [1, 2, 3]; // effective dense array

let foo = {x: 10};
let bar = {#proto: foo, y: 20};

>   SpiderMonkey implements joining for lambdas that do not close over outer lexical variables provided those lambdas are used as the initializer of a property in an object literal, or as the full RHS of assignment to a property of an Object instance. This optimization wins but it requires read and write barriers (which we already have for getters and setters in general). It's complex.
>

Yes, I know that V8 also does it. I.e. if there are no free variables 
and no `eval` of course, there's no sense to save [[Scope]]. (JFTR: 
Python doesn't save not used free variables even in case of using `eval` 
-- yes, it does deep syntactic analysis of inner/ or parent function and 
captures only used bindings in a big single frame, but doesn't form a 
scope chain of small frames).

So it's a normal optimization techique today I think.

> The # prefix means freeze too, and that is required for joining. ES3 left it to implementations to join but that was a mistake that (if implementations had done so; none did after early SpiderMonkey bugs were fixed) creates a mutation side channel.

Yes.

>   See also the ES3 global regexp singleton per lexical regular expression bug.

Yeah, I'm aware about it of course.

Dmitry.


More information about the es-discuss mailing list