block-lambda revival

Brendan Eich brendan at mozilla.com
Thu Jun 23 18:37:12 PDT 2011


On Jun 23, 2011, at 4:07 PM, Rob Campbell wrote:

> I'm liking the block-lambda syntax, I think more than the arrow. One possible shortening could be to exclude the second bar (|) if no argument variables are specified.
> 
> {| // some block of code };

This does not work. How do you know that what follows the first | is not a formal parameter?

Formal parameter syntax looks like expression syntax -- currently Expression covers FormalParameterList. Arrow function syntax relies on this.

/be

> 
> I don't *think* we'd ever start an expression with a single | operator, so there should be no ambiguity.
> 
> On 2011-06-23, at 19:27, Brendan Eich wrote:
> 
>> On Jun 23, 2011, at 3:14 PM, Jorge wrote:
>> 
>>>> Anyway, my 2 cents.  Thanks!
>>> 
>>> {|| ... } for shorter *function* syntax is my favorite too. +1(e9)
>> 
>> Thanks -- I am continuing to maintain arrow function syntax and block lambda revival as strawmen.
>> 
>> Arrows now require only two-token lookahead, ignoring the #!~ prefixes proposed for non-configurable, non-writable, and non-enumerable property assignments in object initialisers. This is in order to support either an object literal body or a braced non-empty block body where the block's first statement is not a labeled statement.
>> 
>> Block lambda revival has more grammar changes, but so far they check out.
>> 
>> 
>>> Also, if any { block } could be a lambda, perhaps we won't need that (nor any new) syntax for block-lambdas.
>> 
>> We would need new syntax still, for formal parameters.
>> 
>> Making blocks be expressions requires unifying the ObjectLiteral and Block productions. I don't know how to do this in without at least two-token lookeahead, and it is not a backward compatible change if done for all places where Statement : Block in the current grammar.
>> 
>> 
>>> Also, I'd prefer to know/see clearly when a function is being call()ed, so I'm not very fond of paren-free calls: foo(bar) is clearly an invocation, unlike foo bar,
>> 
>> Your example is too abstracted to be fair. Concretely, the latter will *always* look like foo {|| bar} ... and never foo bar for any bar.
>> 
>> 
>>> and readability is more important than saving a few keystrokes.
>> 
>> Readability arguments support the paren-free syntax too. You can't win this by selective arguing.
>> 
>> 
>>> The C language is still (and -ISTM- will be for a long time) important, so -IMO- every little bit of JS's C-like syntax is a plus: less to learn: an old, popular, widely used, well-known, and familiar syntax.
>> 
>> C by way of Java, and both are boat anchors. Again, where pray tell is 'function' in C?
>> 
>> 
>>> JS -unlike other languages- is important enough that it does not need to follow these (dubious) trendy fashions to become popular. Nor to survive.
>> 
>> Nothing trendy about Smalltalk blocks unless you are a Rubyist.
>> 
>> 
>>> Proper punctuation aids comprehension and we're programming, not writing quick SMSs.
>> 
>> This is silly, you're making vague arguments that cut both ways.
>> 
>> /be
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110623/9fa8861d/attachment.html>


More information about the es-discuss mailing list