Joshua Warner (Oct 11 2022 at 03:10): Joshua Warner (Oct 11 2022 at 03:10):Hi folks! I'd like to explore making roc's indentation system a little more approachable for people coming from python-like backgrounds, where it's common to indent by a fixed amount relative to the previous line (e.g. 4 spaces) - and having to write out something strange like _13_ spaces to line up with a particular token in the previous line feels very strange.
As quick taste, I'm suggesting that this should parse fine, and do the obvious thing:
fib = \x -> when x is
0 -> 1
1 -> 1
n -> fib(n-1) + fib(n-2)
Versus what is required today:
fib = \x -> when x is
0 -> 1
1 -> 1
n -> fib(n-1) + fib(n-2)
(indenting past the when)
See this comment on github for a (more) complete exploration of the implications here.
Thoughts?
Chris Duncan (Oct 11 2022 at 03:22):I wouldn't be surprised that we adopt something similar to Elm's Style Guide.
Joshua Warner (Oct 11 2022 at 03:49):I think this particular "bad" example is relevant here:
type Boolean = Literal Bool
| Not Boolean
| And Boolean Boolean
| Or Boolean Boolean
Changing the type name Boolean will change the indentation on all subsequent lines. This leads to messy diffs with indentation changes that provide no meaningful value.
That's relevant to the fib example above (even leaving off the when) - and lambdas in general. Same if you wanted to assign a when to a variable - the name of the variable would change the indentation under the current roc rules.
Brendan Hansknecht (Oct 11 2022 at 03:50):At first I was annoyed by this. After using and writing it a lot, I think both of those formats aren't great for readability.
I think the reasonable format for a when right inside a function is:
fib = \x ->
when x is
0 -> 1
1 -> 1
n -> fib(n-1) + fib(n-2)
Note: number of spaces/tabs is arbitrary
Joshua Warner (Oct 11 2022 at 03:51):Yep, I agree on the readability of your example; nested lambda and when is perhaps a bad example.
Brendan Hansknecht (Oct 11 2022 at 03:53):Looking at your other example, I see your point more, I think I still in in the just add a new line camp, but many other options may be much better than being dependent on the length of the variable name.
Richard Feldman (Oct 11 2022 at 05:39):I do like x = when ... though
Richard Feldman (Oct 11 2022 at 05:40):which has the same considerations as the lambda from the parser's perspective, even if the formatter adds a newline in the lambda case but not the = case
Anton (Oct 11 2022 at 05:45):x is quite a bit shorter then the average variable name :p
I think in most cases having the when on a new line will be easier to read.
Brendan Hansknecht (Oct 11 2022 at 05:45):I used to write x = when ... but I feel like I didn't know the proper parsing rule and just started always adding new lines to make it work correctly. So I guess at first I tried to writing in a kinda python like way.
Joshua Warner (Oct 11 2022 at 14:44):I'm totally on board with having the formatter fix the newlines/indentation to whatever we decide is the "right / canonical" format.
For me this is mostly about making sure we can teach that format - which is to say, the compiler can say "Yeah I see what you're trying to do; let me help you out (by auto-formatting)".
I'd even be on board with emitting _warnings_ in case the indentation is sufficiently egregious.
...but that all depends on the parser being able to understand the user intent in those cases.
Richard Feldman (Oct 17 2022 at 04:29):ok, I'm totally sold on this approach
Richard Feldman (Oct 17 2022 at 04:30):it seems like there's a separate formatting question, but having the parser accept more things (which the formatter can later change) seems like a win to me!
Joshua Warner (Oct 19 2022 at 02:34):Awesome! First PR implementing that: https://github.com/roc-lang/roc/pull/4337
Last updated: Jun 16 2026 at 16:19 UTC