4 ms·

# Function Shorthand #### I like how functions in js can be `arg => result`. In F# I have to do `fun arg -> result` with the `fun` keyword. It makes sense sinc

# Function Shorthand #### I like how functions in js can be `arg => result`. In F# I have to do `fun arg -> result` with the `fun` keyword. It makes sense since `MyArgType -> MyResType` is a type signature in f#, but I feel like the compiler can just check if the arguments are references to types or are argument bindings. # Multiline Lists/Arrays #### I like how F# doesn't require delimiters for multiline lists. So I can do `let myList = [1; 2; 3]` or let myList = [ 1 2 3 ] # Regex Literal #### I like how in Crystal instead of doing `/my[regex]/` i can do `%r(my[regex])` where the parenthesis can be any brace type (like "(", "{", "<", "[") so I don't have to escape any characters. # Argument Accessor Shorthand #### In Crystal, you can use an ampersand to bind and access a property on an object, instead of writing the verbose form with a function. So this ["a", "b"].join(",") { |s| s.upcase } can be written as ["a", "b"].join(",", &.upcase) If this were available in F#, for example, instead of ["a"; "b"] |> List.map (fun s -> s.ToUpper()) |> String.concat "," I could do ["a"; "b"] |> List.map &.ToUpper() |> String.concat ","

dan-robertson 4y ago
The function syntax I like even more is one with implicit arguments so you don’t have to name them, e.g. waiting = sum workers #(%.in_queue + %.in_flight) Clojure has some syntax like this though it isn’t needed for the most obvious use-case of functions to extract fields because keywords, which are usually used for map keys, are implicitly functions that look themselves up in their arg, e.g. (:bar { :foo 3, :bar 2 }) ; => 2
masklinn 4y ago
> 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
hencq 4y ago
Re: the argument accessor shorthand, there seems to be a proposal for exactly that (using _ instead of &): https://github.com/fsharp/fslang-suggestions/issues/506#issuecomment-758732114 https://github.com/fsharp/fslang-suggestions/issues/506#issu...
gpderetta 4y ago
> In F# I have to do `fun arg -> result` with the `fun` keyword meanwhile in C++: [&](auto arg) { return result; } You don't know how good you have it.
still_grokking 4y ago
You can have this in Scala. List("a", "b").map(_.toUpperCase).mkString(",") It's the shorthand for: List("a", "b").map(elem => elem.toUpperCase).mkString(",") (Which shows the firstly proposed feature :-))

dan-robertson 4y ago

The function syntax I like even more is one with implicit arguments so you don’t have to name them, e.g. waiting = sum workers #(%.in_queue + %.in_flight) Clojure has some syntax like this though it isn’t needed for the most obvious use-case of functions to extract fields because keywords, which are usually used for map keys, are implicitly functions that look themselves up in their arg, e.g. (:bar { :foo 3, :bar 2 }) ; => 2

masklinn 4y ago

> 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

hencq 4y ago

Re: the argument accessor shorthand, there seems to be a proposal for exactly that (using _ instead of &): https://github.com/fsharp/fslang-suggestions/issues/506#issuecomment-758732114 https://github.com/fsharp/fslang-suggestions/issues/506#issu...

gpderetta 4y ago

> In F# I have to do `fun arg -> result` with the `fun` keyword meanwhile in C++: [&](auto arg) { return result; } You don't know how good you have it.

still_grokking 4y ago

You can have this in Scala. List("a", "b").map(_.toUpperCase).mkString(",") It's the shorthand for: List("a", "b").map(elem => elem.toUpperCase).mkString(",") (Which shows the firstly proposed feature :-))