May 24-26 rough meeting notes

Brendan Eich brendan at
Wed Jun 1 10:35:52 PDT 2011

On Jun 1, 2011, at 10:07 AM, Jorge wrote:

>>> A block:
>>> { noLabelHere ... }
>> We didn't talk about this change. It is yet another migration early-error to consider.
> But it's not very usual to begin a block with a label.

You're right, and it can be an ArrowBodyBlock, not a backward-compatible Block, so this is only a refactoring-from-function-to-arrow-syntax tax. Good idea.

>> It's certainly simpler than a more powerful parsing algorithm than LR(1), 
> If you 
> 1.- keep the familiar { block } syntax for first class blocks, and 
> 2.- use {|| ... } for shorter functions syntax and
> 3.- keep the (obligatory) parens as the call() operator
> wouldn't we gain everything in the arrow syntax and block lambdas strawmen, except for paren-freeness ?

No, some people object to the cleverness of block-lambdas, the TCP preservation for break, continue, return, and |this|, and the completion-return too.

Paren-free syntax for block-lambdas as control abstractions is controverisal, but less so, and IMHO trumped up (since when was C# in its multi-version glory designed holistically at 1.0? LINQ and other innovations have come relatively quickly).

Block-lambdas are more divisive because they introduce novel runtime semantics, akin to throwing uncatchable-except-by-the-VM exceptions.

Arrow function syntax is just syntax, so it is an easier sell, provided the grammar and semantics can be added to the ECMA-262 framework without too much trouble.

> And, wouldn't that be easier for the current (proven) parsers, and pose almost zero risks in this respect ?

The parsing problems of arrows are really only in the ECMA-262 spec-space, not in real implementations.

> And, wouldn't that be in line the already known, much appreciated by many of us, current JS (and C) style ?
> { block }( call ) or {|| ... }( call )

Since when can you call a block in JS or C?

A function expression is not a block, it starts with 'function(' at the least.

> foo bar baz ... wtf ?  foo(bar(baz)) ? foo(bar)(baz) ? foo(bar)(baz)() ? meh! This syntax introduces ambiguities !

Not the way the strawman grammar works. Did you read it?

Here you seem to be inveighing against the paren-free CallWithBlockArguments production, not against arrow function syntax. Yet you switch targets immediately:

> Do David and Jeremy like it ? Good for them. Do JavaScripters like it ? The least we can say is that it's quite polemical : <>

What are you talking about now? Arrows or call-with-block-lambda-argument paren-free calls? The two are entirely separate strawmen, the latter part of block-lambdas.

If by David you mean DHH, didn't he endorse CoffeeScript, which uses arrow function syntax, and not any Ruby-ish block-lambda proposal from me? Please keep your arguments straight!

>> but we might want to cross that bridge anyway for arrow functions.
> <fwiw>
> Arrow syntax is extraneous to JS developers. It's an unnecessary, radical style change. And ugly: there are JS developers that just *don't*like* it. 

People say that about block-lambdas and not just for the non-function-looking syntax -- especially for the semantics, which are novel.

> So, why ? 

I think the shoe is on the other foot.

Look, I wrote up both and to give both the arrow fans (not just CoffeeScript, it is in many languages and math-y notation systems) and block-lambdas (originated in Smalltalk, also in a more layered form in Ruby) both a fair shake.

Don't shoot the messengers who want only one, or neither. And don't shoot me for drafting these. JS's function syntax with mandatory return in braced body is too long. But fixing that is not a simple matter of *only* shortening function to some ugly and conflicted punctuator. It's not a matter of pretending block-lambdas are blocks and are already callable. It requires careful work to meet several often-conflicting goals and requirements.

> Paren-free(ness) is a fashion: foo bar baz, what's a function, who's calling who ? with which parameters ? Meh! Ambiguities.

How about you stop ranting and read the block-lambda grammar.

> </fwiw>
>> If we succeed there, we may not need such an incompatible restriction on labels.
> -1

-1 on what, the incompatible change being rejected? It isn't necessary anyway: we can split Block and ArrowBodyBlock or anything like it. So cheer up!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list