Danielo Rodríguez (Oct 26 2022 at 16:21): Danielo Rodríguez (Oct 26 2022 at 16:21):Hello! I have been suggested to discuss this topic here: https://github.com/roc-lang/roc/issues/4404
So here is a copy paste of it:
Hello, this project looks super impressive, it ticks almost all checks in my list of super nice things to have, except for easiness of typing :grinning_face_with_smiling_eyes:.
In a functional language, where you are going to e writing functions all the time I think the ergonomics are very important.
Currently it requires at least 4 special characters, which are not commonly available in keyboard layouts other than US.
I know there is some history behind the syntax, but I don't think it's worth it for a reference.
In comparison, other space sensitive functional languages like F have a much more succinct syntax.
Regards
Brendan Hansknecht (Oct 26 2022 at 16:36):Aren't most of these symbols already required for programming in general? \x -> ...
-: Required for basic op of subtraction>: Required for basic op of greater than\: Maybe not need, but is the escape characterNot saying it can't be made better, but they don't feel particularly uncommon in programming (which may be another issue)
Anton (Oct 26 2022 at 17:15):I think \ is the only/main problem.
It is kind of a pain on azerty.
Anton (Oct 26 2022 at 17:25):It's hard to think of an alternative that looks good in all cases in for example Parser/Core.roc. I do think every major editor would allow you to set up a convenient shortcut to type \.
Zeljko Nesic (Oct 26 2022 at 19:27):Even better after you written somefn = and hit double space it should expand to somefn = \ _ ->
Richard Feldman (Oct 26 2022 at 21:41):so on that keyboard I guess the annoyance is that you have to hold shift while pressing the key?
the options I've seen in other languages aren't much better:
(x, y) => in JS and CoffeeScript|x, y| in Ruby and Rust Georges Boris (Oct 27 2022 at 01:47):I may be biased but the current implementation seems great to me especially since we're able to define functions in a clear way as arguments without even using parenthesis. Felt great while doing the advent of code exercises.
Kevin Gillette (Oct 27 2022 at 03:19):I wonder if the \ is even necessary with the other syntactic tradeoffs that Roc has made? _Applied_ arguments are space separated, while parameters are comma separated, so you'd only need as much token lookahead as is needed to find the comma or the -> to know it's a function? For simple params, that's two tokens, but I guess for destructuring that would be more.
Anton (Oct 27 2022 at 07:17):so on that keyboard I guess the annoyance is that you have to hold shift while pressing the key?
You actually have to do Ctrl+Alt+8 or Alt Gr+8
Danielo Rodríguez (Oct 31 2022 at 05:58):Kevin Gillette said:
I wonder if the
\is even necessary with the other syntactic tradeoffs that Roc has made? _Applied_ arguments are space separated, while parameters are comma separated, so you'd only need as much token lookahead as is needed to find the comma or the->to know it's a function? For simple params, that's two tokens, but I guess for destructuring that would be more.
I have that same feeling, if it is required at all. True that most of those tokens are common, that doesn't make them any easier to type. All the programming languages are focused on US-Qwerty layout. I don't want to go the the extreme other languages have with just using keywords, but for that same reason it's very easy to type them in any keyboard. Lua for example, just requires function and end, which is tedious to write, but once you are fast at typing words you can type it super easily.
Anton (Oct 31 2022 at 07:56):Kevin Gillette said:
I wonder if the
\is even necessary with the other syntactic tradeoffs that Roc has made? _Applied_ arguments are space separated, while parameters are comma separated, so you'd only need as much token lookahead as is needed to find the comma or the->to know it's a function? For simple params, that's two tokens, but I guess for destructuring that would be more.
\ may not be required for parsing but I do think some symbol or word is necessary for readability.
Danielo Rodríguez (Oct 31 2022 at 09:36):there is the -> isn't it?
Anton (Oct 31 2022 at 10:07):Yeah, but it is nice to have it at the start because you immediately know what you are dealing with.
This might also lead to confusion for when match arms where we also use just ->.
Qqwy / Marten (Oct 31 2022 at 11:29):There are other languages in which the \ is written as a keyword instead, like lambda (Lisp, Python) or fn/fun (Elixir, Clojure, Erlang, F#, OCaML).
Qqwy / Marten (Oct 31 2022 at 11:30):There's also C++ which does [](){}. To this day I struggle a little to take this syntax seriously :sweat_smile: .
Qqwy / Marten (Oct 31 2022 at 11:32):(Recent C++ even allows []<>(){} for anonymous function templates)
Anton (Oct 31 2022 at 12:14):I'd be ok with fn, some examples:
oneOrMore : Parser input a -> Parser input (List a)
oneOrMore = fn parser ->
const (fn val -> fn vals -> List.prepend vals val)
|> apply parser
many : Parser input a -> Parser input (List a)
many = fn parser ->
buildPrimitiveParser fn input ->
manyImpl parser [] input
map3 : Parser input a, Parser input b, Parser input c, (a, b, c -> d) -> Parser input d
map3 = fn parserA, parserB, parserC, transform ->
const ( fn a -> fn b -> fn c -> transform a b c)
|> apply parserA
What is the precedence of \ today? Is a top level declaration special cased in the grammar, and does \ otherwise have higher (tighter binding) precedence than |> ?
Anton (Oct 31 2022 at 13:40):The relevant function
Relevant comment from that function:
// Once we see the '\', we're committed to parsing this as a closure.
// It may turn out to be malformed, but it is definitely a closure.
From this I would conclude that \ has the highest precedence as long as you're not inside a char or string of course.
I believe top level declarations are special cased.
Danielo Rodríguez (Nov 02 2022 at 09:22):Anton said:
I'd be ok with
fn, some examples:oneOrMore : Parser input a -> Parser input (List a) oneOrMore = fn parser -> const (fn val -> fn vals -> List.prepend vals val) |> apply parser
fn looks like a good compromise
Danielo Rodríguez (Nov 02 2022 at 09:22):faster to type for me than any special character
Anton (Nov 02 2022 at 10:12):What do other people think?
Georges Boris (Nov 02 2022 at 12:33):My 2c - I'm still biased towards \ but whatever people agree with I'm good. The problem I have with keywords is that they aren't as clear when using them together with other arguments imo.
List.map list fn x -> x + 2
List.map list \x -> x + 2
To me it becomes unclear if the first list map receives 2 args or 3 args with a weird forward passing to x + 2. Highlighting could make it better but I don't think color should be the only form of clear distinction.
Georges Boris (Nov 02 2022 at 12:34):(and the lack of necessary parenthesis is a current win for Roc, coming from Elm)
Anton (Nov 02 2022 at 12:49):Yeah, I agree that \ is visually better.
Richard Feldman (Nov 02 2022 at 13:43):yeah I don't think making it easier to type on some keyboards (and harder on most keyboards, notably; fn takes twice as long for almost everyone to type than \) at the cost of making it harder to read for everyone on all keyboards is the right tradeoff :big_smile:
Richard Feldman (Nov 02 2022 at 13:45):my conclusion is that we should leave it as-is
Richard Feldman (Nov 02 2022 at 13:45):I appreciate the discussion!
Kevin Gillette (Nov 02 2022 at 13:49):lol, twice as long to type is a big deal when more than two keypresses is involved (arguably \ might be slower to type despite that due to travel distance)
That said, I've struggled to think of an alternate to \ that looks better. My primary issue with it was that it reads to a C family programmer as a character escape (i.e. \n reads like a newline caught outside of quotes).
I believe |a, b| was the next best option, but it isn't much better than \, and the backslash isn't a hard thing to get used to, provided that we make it the first thing someone learns in a tutorial
Brian Hicks (Nov 02 2022 at 13:59):I thought there was consensus in functional languages around \ but it doesn't look like there is. \ in Haskell and Elm; fun in F#, Erlang, and OCaml; fn in Elixir. Seems like all the options have been fine, leaving it up to aesthetics. \ seems fine to me! (Not that I was asked.)
Georges Boris (Nov 02 2022 at 14:03):elixir is not a good example here imo :sweat_smile:
Enum.map(list, fn x -> x + 1 end)
or
Enum.map(list, & &1 + 1)
elixir might be great in 99 things but lambda syntax ain't one
Danielo Rodríguez (Nov 02 2022 at 17:03):Richard Feldman said:
yeah I don't think making it easier to type on some keyboards (and harder on most keyboards, notably;
fntakes twice as long for almost everyone to type than\) at the cost of making it harder to read for everyone on all keyboards is the right tradeoff :big_smile:
Fair point, but "twice as long" is super relative. It takes me two keystrokes, even it if it is a chord it still two keystrokes, and fn takes me the same amount to keys to press. :stuck_out_tongue:
Théo Cavignac (Nov 02 2022 at 19:51):Brian Hicks said:
I thought there was consensus in functional languages around
\but it doesn't look like there is.\in Haskell and Elm;funin F#, Erlang, and OCaml;fnin Elixir. Seems like all the options have been fine, leaving it up to aesthetics.\seems fine to me! (Not that I was asked.)
As a AZERTY keyboard user I don't like \ syntax because it force me to do a weird twisted keychord. My professional latex usage doesn't help.
Martin Stewart (Nov 02 2022 at 20:00):Instead of modifying the syntax, could the Roc IDE have a hotkey to
insert a \?
Richard Feldman (Nov 02 2022 at 20:49):absolutely!
Zeljko Nesic (Nov 03 2022 at 01:23):or by a voice command or to train our neural circuits to send "create a lambda" input to Mac.
Main point of the editor is to provide you with the affordance of creating a lambda, as a verb.
Last updated: Jun 16 2026 at 16:19 UTC