5 ms·

> I feel like the compiler can just check if the arguments are references to types or are argument bindings. 1. this is absolutely terrible because now you nee

> I feel like the compiler can just check if the arguments are references to types or are argument bindings. 1. this is absolutely terrible because now you need feedback from the type checker to know how to parse the program 2. it is furthermore also ambiguous with function application, requiring arbitrary lookahead to disambiguate, also not a fun thing to do JS gets away with it because the sigil was not previously used and it only requires a single lookahead to parse, as only single-parameter anonymous functions can have "bare" parameter lists.

devmunchies 4y ago
Yeah, then maybe just shorten `fun` to `f` or `fn` like elixir. I think even just one char makes a difference over thousands of LoC.
- masklinn 4y ago
  In haskell (and elm) it's `\` which is quite OK (and also a nod to the lambda symbol λ). But yes "fn" is quite nice (taking over "f" is a bit much). And a few characters can definitely degrade the experience, especially as "u" and "n" are typed with the exact same finger. Anonymous functions were definitely one of my least favorite features in Erlang, not because they don't work well but because their leading keyword is "fun" and there's an arrow between the (parenthesised) parameters and body and they also have a closing keyword "end": map(fun(X) -> 2 * X end, [1,2,3,4,5]). That's a bit much. But HoFs in general are quite awkward, as referring to a named function also requires the `fun` leading keyword, and requires specifying the arity, so map(fun double/1, [1,2,3,4,5]). after having defined the function as double(X) -> 2 * X. (as you can see Erlang would really rather you defined named functions).
jlokier 4y ago
It doesn't need feedback from the type-checker. The type is not required, only whether a symbol is a type symbol. So it is enough to have feedback from the lexical scope, which can be tracked during parsing without any type analysis. It's a compromise, but a useful and simple one. C has been doing it since the 70s ("typedef").
still_grokking 4y ago
This works fine in Scala. And no, they don't need feedback form the type-checker to parse a program. Also there is no ambiguity with application. val f: Any => String = any => any.toString

devmunchies 4y ago

Yeah, then maybe just shorten `fun` to `f` or `fn` like elixir. I think even just one char makes a difference over thousands of LoC.

masklinn 4y ago
In haskell (and elm) it's `\` which is quite OK (and also a nod to the lambda symbol λ). But yes "fn" is quite nice (taking over "f" is a bit much). And a few characters can definitely degrade the experience, especially as "u" and "n" are typed with the exact same finger. Anonymous functions were definitely one of my least favorite features in Erlang, not because they don't work well but because their leading keyword is "fun" and there's an arrow between the (parenthesised) parameters and body and they also have a closing keyword "end": map(fun(X) -> 2 * X end, [1,2,3,4,5]). That's a bit much. But HoFs in general are quite awkward, as referring to a named function also requires the `fun` leading keyword, and requires specifying the arity, so map(fun double/1, [1,2,3,4,5]). after having defined the function as double(X) -> 2 * X. (as you can see Erlang would really rather you defined named functions).

jlokier 4y ago

It doesn't need feedback from the type-checker. The type is not required, only whether a symbol is a type symbol. So it is enough to have feedback from the lexical scope, which can be tracked during parsing without any type analysis. It's a compromise, but a useful and simple one. C has been doing it since the 70s ("typedef").

still_grokking 4y ago

This works fine in Scala. And no, they don't need feedback form the type-checker to parse a program. Also there is no ambiguity with application. val f: Any => String = any => any.toString