Minor change to case expression syntax

[robinheghan]

In brief, this proposes to change the case..of syntax from

case x of
  1 -> «one»
  2 -> «two»
  _ -> «other»

To

case x of
| 1 -> «one»
| 2 -> «two»
| _ -> «other»

This has two benefits:

1. Case expressions isn’t as sensitive to whitespace as before (nested case expressions will need parens)
2. It’s easier to copy a custom type definition to use as the baseline for a case expression (no need to strip the leading prefix from each branch).

Finally, I’m also proposing that it’s ok for custom type definitions to begin with a pipe before the first constructor, as is the case below

type Demo =
  | One
  | Two
  | Three

Alternatives

One could also choose to use a delimiter to determine when a case expression ends, like in the example below

case x of
  1 -> «one»
  2 -> «two»
  _ -> «other»
end

The benefit of this is that you wouldn’t require parens for nested case expressions, or delimiters to signal the start of a branch. The counter argument is that Gren doesn’t typically rely on delimiters to limit the scope of expressions or statements, so it feels a little out of place. Also, depending on the delimiter, it could collide with valid variable names.

[laurentpayot]

Here are my humble opinions:

About pipe case indentation

I would rather keep on using indentation than the pipe operator that was previously used only for sum types. Indentation is what makes code readable by indicating grouping without noise in the code that all these pipes and parentheses would introduce.

About custom type definitions with a pipe before the first constructor

In sum types the pipe character | is a bit like a logical OR between types. Beginning with one would be a logical nonsense.

About end or another delimiter for case

As you said using end with case whereas Gren does not use it elsewhere would be weird and once again add more noise in the code.

[robinheghan]

Thank you for your input!

Indentation is what makes code readable

I don't disagree with this principle, however I've frequently had the experience that I'm, for one reason or another, missing a space in a crucial place so that (a) my code doesn't compile and (b) my code isn't formatted by the formatter. I'd much rather rely on gren format for making the code nice, than to have to make the code read nicely for it to compile at all.

Beginning with one would be a logical nonsense.

I see your point. Allowing a leading pipe makes it easier to move branches around while refactoring, though.

[laurentpayot]

I see your points too. But remember that code is read much more often than it is written :wink:

[laurentpayot]

I just discovered these proposed changes actually are like adopting the F# syntax. Interesting :thinking: Is Gren moving towards something like (Elmish + Fable)?

[robinheghan]

actually are like adopting the F# syntax

Nah. The proposals are trying to fix what I consider to be problems with the syntax inherited from Elm, and both OCaml (not F#), Haskell and PureScript are natural to draw inspiration from.

Is Gren moving towards something like Elmish + Fable?

Not sure what that means 😅 But no, we have no plans to adopt more features from Ocaml/F#/Haskell than what is currently proposed.

[robinheghan]

Rejecting this proposal.

I believe the whitespace sensitivity can be improved without any change in syntax, and the other points not directly related to whitespace sensitivity aren't important enough to change.