( -> ) -> fails with UNEXPECTED '->'

[shesek]

It seems like you can't pass an anonymous function as an argument to an anonymous function. Sorry if its a duplicate, but its really hard to search for previous issues here.

For anyone else encountering it, you can work around that by assigning the anonymous function argument to a variable. See: https://github.com/shesek/trello-hide-lists/blob/master/trello-hide-lists.user.coffee#L7

[vendethiel]

() -> is a function declaration.

its really hard to search for previous issues here.

You need a bit of training :p .

[jashkenas]

Yep. You can use parens to disambiguate if you'd like.

[michaelficarra]

Huh. I would consider this a bug. CSR handles this fine. It's not like it's ambiguous like (a = ->) ->.

[vendethiel]

It's a bit more complicated in this parser considering parameters are tagged backwards. else if tok[0] is '(' could probably check for tokens[i+1] to be an id?

[jashkenas]

I'm not so sure it should be parsed. If:

( -> ) -> 

Is effectively ( func )(->)

But:

( func ) ->

is effectively ( param ) ->

... that strikes me as unexpected and pretty inconsistent. We usually try to avoid those -- "oh we can parse it as long as it's not an identifier", cases.

[epidemian]

Agreed with @jashkenas. Are there any other cases where (<something>) -> would be parsed as (<something>)(->) instead of raising an error or compiling it as a function declaration where <something> are the parameters of the function (which can be more complex than just a list of identifiers, due to parameter destructuring and default parameters) ?

[michaelficarra]

@jashkenas: I'd argue consistency is more important than helping someone who is making a naive error.

-> -> # works
-> (->) # works
(->) -> # curiously doesn't

fn0 fn1 -> # works
(fn0) fn1 -> # works
fn0 (arg) -> # works
fn0 fn1 (->) # works
fn0 (fn1 ->) # works
(fn0 fn1) -> # curiously doesn't

These seemed so obvious to me, I just assumed they were bugs and added tests for them in my compiler. I also didn't have to take any special provisions to support these cases, since the parser will arrive naturally at them.

[satyr]

(which can be more complex than just a list of identifiers, due to parameter destructuring and default parameters) ?

didn't have to take any special provisions to support these cases, since the parser will arrive naturally at them.

Amusing to see ({a, b: [c, d.e]}) -> suddenly becomes a call on Redux when e.g. one forgets the , after c.

[jashkenas]

Let's figure this point out -- I'm fairly sure that the consistent rule is to say: "Parentheses immediately before a function literal are always an argument list". They get highlighted that way (independent of their contents), and it's a bit easier to map mentally. For example:

(a) ->
({a: b}) ->

(->) ->
({a: ->}) ->

func() ->

In all of those examples, the parentheses should be the parameter list for the function. It means that #2 and #3 are syntax errors, but I think that's good. Generalizing your current rule that if the contents aren't an identifier, it's not a parameter list makes for very tricky cases. What if it's an object literal? (Currently a destructuring assignment.) If it's an object literal that happens to have a value that's not an identifier, does it suddenly stop being a parameter list?