On 2011-06-23, at 22:37, Brendan Eich wrote:
> 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?
Ah, right. I guess you'd need to scan the full block first and look for the
second | and then do the right thing for each case. Messy.
> 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
>>> [email protected]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
