Block lambda is cool, its syntax isn't

Brendan Eich brendan at mozilla.com
Fri Jan 20 22:17:11 PST 2012


> Axel Rauschmayer <mailto:axel at rauschma.de>
> January 20, 2012 9:24 PM
>
> - Hard to type: reading is far more important than typing, it is very 
> easy to adapt tools to help with typing.

ƒ is not particularly readable IMHO. It's florin, not mathematical 
notation I've ever seen. Anyway we can't assume the compatibility break 
is ok since it can occur in operand context in any expression.
>
> - Not ASCII: I hardy every encounter non-UTF text files, any more. 
> Non-ASCII seems to work well for Fortress.

Fortress, please. I invite @samth to comment now. I admire Fortress, but 
it is not an exemplar or nearby language for JS.
>
>> I think "use fn;" (real pragma syntax), with the low-precedence 
>> assignment-expression fn (params) assign-expr production, wins. What 
>> do you think?
>
> Having fn would be sweet. For many kinds of pragmas, it would be great 
> if one could configure these per project (or per directory). Then one 
> could put legacy code in one directory and ES6 code in another. And 
> the weight of the pragmas would be negligible. Not sure how to do 
> this, though; reminds me very loosely of CSS (centralized management 
> of style).

You make a good point: "use fn;" may be too much to require in every 
<script> element content.
>
> Would fn make sense as an ES6 breaking change? I’d expect many people 
> to be strongly in favor, possibly as many strongly opposed.

Don't forget that JQuery uses fn as an identifier (and not just 
following a dot) all over.
>
> Possible research (applies to ƒ, too):
> - Poll people for their opinion

These are not decisive. I've been straw-polling audiences for a while. 
Block-lambdas are doing well, but one must ask "nothing, just 
'function'" and usually get a stronger response than any new syntax.

> - Search JS code bases for how often the identifier "fn" is used (how?).

See JQuery sources. Unconditionally reserving 'fn' is a non-starter 
IMHO. Recall also that we are trying to hew to "One JavaScript" -- few 
to no refactoring woes moving code in and out of a module {...} 
container or "use strict"; code block.

/be



More information about the es-discuss mailing list