Oliver Hunt wrote:
> On Jul 26, 2013, at 8:50 AM, Domenic Denicola<domenic at domenicdenicola.com>  wrote:
>
>> Why do arrow functions require a parameter list and a body? That is, none of the following are allowed:
>>
>> - `=>  foo`
>
> I guess this could be lexically unambiguous, but i'm unconvinced that the "win" of losing two characters in the strictly less common no parameters is worth the syntactic confusion

For the record, I validated toy grammars and making arrow's parameter 
list optional is completely unambiguous.

>> - `bar =>`
>> - `=>`
>
> I think an optional tail would be a huge coding hazard - a typo could result in bizarre behaviour, take:
>
> blah(=>,5)
>
> vs
>
> blah(=>5)

Perhaps more likely to be a problem:

   var empty = =>
   callLater(empty, "sorry");

due to left out semicolon at end of first line.

>> Instead you need the more-verbose
>>
>> - `() =>  foo`
>
> Honestly I'm not sold on the {} free production, but i understand the arguments for it.  Randomly (and because i'm too lazy to check) how would
> a =>  b =>  c

a => (b => c)

of course.


> produce?  I mean aside from making the maintainers cry.

Maintainers put on the big-kid pants every day. We have lovely theory of 
formal languages and parsers, there's no issue with chained =>. It's 
actually good notation from Math and CS, supported directly by many 
languages.

/be

Oliver Hunt wrote:
> On Jul 26, 2013, at 8:50 AM, Domenic Denicola<domenic at domenicdenicola.com>  wrote:
>
>> Why do arrow functions require a parameter list and a body? That is, none of the following are allowed:
>>
>> - `=>  foo`
>
> I guess this could be lexically unambiguous, but i'm unconvinced that the "win" of losing two characters in the strictly less common no parameters is worth the syntactic confusion

For the record, I validated toy grammars and making arrow's parameter 
list optional is completely unambiguous.

>> - `bar =>`
>> - `=>`
>
> I think an optional tail would be a huge coding hazard - a typo could result in bizarre behaviour, take:
>
> ```js
> blah(=>,5)
> ```
>
> vs
>
> ```js
> blah(=>5)
> ```

Perhaps more likely to be a problem:

```js
var empty = =>
callLater(empty, "sorry");
```

due to left out semicolon at end of first line.

>> Instead you need the more-verbose
>>
>> - `() =>  foo`
>
> Honestly I'm not sold on the `{}` free production, but i understand the arguments for it.  Randomly (and because i'm too lazy to check) how would
> ```js
> a =>  b =>  c
> ```

```js
a => (b => c)
```

of course.


> produce?  I mean aside from making the maintainers cry.

Maintainers put on the big-kid pants every day. We have lovely theory of 
formal languages and parsers, there's no issue with chained `=>`. It's actually good notation from Math and CS, supported directly by many languages.