Matthias Toepp (Apr 19 2023 at 00:46): Matthias Toepp (Apr 19 2023 at 00:46):Any chance we could use elif rather than else if?
elif is easier to type, cleaner to read and it's used in one of the very most popular languages. Popularity, beauty and efficiency, all in one package!
# elif
# Notice that the conditions are closer to lining up vertically
# so the eye doesn't have to move as far to the right to scan
# the conditions. There's less "syntax noise".
if b > a then
Stdout.line "b is greater than a"
elif a == b then
Stdout.line "a and b are equal"
else
Stdout.line "a is greater than b"
vs
# else if
if b > a then
Stdout.line "b is greater than a"
else if a == b then
Stdout.line "a and b are equal"
else
Stdout.line "a is greater than b"
Why is it easier to read?
Brendan Hansknecht (Apr 19 2023 at 01:57):Oh, nvm, missed the comment
Brendan Hansknecht (Apr 19 2023 at 02:37):Personally I think main advantage of else if is that's what you say when talking about branches.
Brendan Hansknecht (Apr 19 2023 at 02:37):elif has no real meaning and is not spoken.
aside: I think python is the only popular language that uses it. Most (all?) other popular languages use else if. So I think popularity would be an argument against elif.
Brendan Hansknecht (Apr 19 2023 at 02:38):But all of that is super minor. I think either of fine and just a matter of minor preference
Matthias Toepp (Apr 19 2023 at 03:16):Brendan Hansknecht said:
elifhas no real meaning and is not spoken
Personally I think one advantage ofelse ifis that's what you say when talking about branches.
I take your point, and there is something to that. elif is a contraction of else if like when we say he'll or I've. It's like saying Str instead of String (it saves typing) and the meaning is easy enough to grasp.
It will probably be uncomfortable at first to people who are not used to it, but may be appreciated after some time.
I believe the case here is stronger compared to Str because Str.append would be part of a line that is read linearly, but with conditions people would benefit from having the conditions line up more closely vertically (similar to how match conditions line up vertically).
Brendan Hansknecht (Apr 19 2023 at 03:24):I overall agree. elif is a tiny bit nicer for alignment. I still mostly think it is just a flavor/taste and people will quickly get used to either. Any decent syntax highlighter will enable focusing on the conditionals without much concern for the keywords.
Anton (Apr 19 2023 at 08:08):I'm in favor of elif, the difference in alignment of the conditions bothers me a lot so I really appreciate minimizing that.
Anton (Apr 19 2023 at 08:12):It seems out there, but I could even go with ef
Georges Boris (Apr 19 2023 at 09:50):I'm in favor of not having if/else and instead having something similar to elixir's cond block.
if
b > a -> ...
b == a -> ...
-> ...
which is basically a when block but just using guard clauses and it saves up two keywords (then / else)
Anton (Apr 19 2023 at 09:59):Yeah, it seems like the best option. We've talked about it before, I think the only real downside was that it will not be familiar.
Georges Boris (Apr 19 2023 at 10:01):then again... lots of Roc won't be :grinning_face_with_smiling_eyes: lets DISRUPT the if statement haha
Anton (Apr 19 2023 at 10:02):if b > a then
Stdout.line "b is greater than a"
else if a == b then
Stdout.line "a and b are equal"
else
Stdout.line "a is greater than b"
vs
if
b > a ->
Stdout.line "b is greater than a"
a == b ->
Stdout.line "a and b are equal"
_ ->
Stdout.line "a is greater than b"
I would use a wildcard for the else
Anton (Apr 19 2023 at 10:02):What we have now looks like a mess in comparison
Georges Boris (Apr 19 2023 at 10:08):it could use either a wildcard or a true since that would bypass the rest of the options. (I think it should take both since imo the wildcard looks a lot cleaner)
Matthias Toepp (Apr 19 2023 at 10:42):elif is a compromise that makes an improvement (but doesn't fully solve the alignment/noise issue). One option could be to unite if and when ... is (and actually simplify the language) but i don't know how to do that without unusual syntax. Even though people talk about using up the strangeness budget... I think in something like this... because it's so fundamental, it's ok to have a bit of strangeness.
Gleam:
case some_bool {
True -> "It's true!"
False -> "It's not true."
}
let description =
case True {
a > b -> "It's true!"
a < b -> "It's not true."
_ -> "default"
That's how Gleam is doing conditionals for now. I'm not saying that that is a great solution, just added the gleam code as a point of reference. I'm not sure they are all that happy with that. I think they are just going with it for now because it doesn't add to the language.
@Georges Boris
I would love elif but love another solution as you're suggesting that provides full alignment even more. I floated elif because I didn't hope for more considering the "strangeness budget" arguments, but personally I don't think an unusual syntax here is going to make or break roc. I think we have more in the strangeness budget to spend, and underspending is also something that we could regret later.
Matthias Toepp (Apr 19 2023 at 10:59):Anton said:
if b > a then Stdout.line "b is greater than a" else if a == b then Stdout.line "a and b are equal" else Stdout.line "a is greater than b"vs
if b > a -> Stdout.line "b is greater than a" a == b -> Stdout.line "a and b are equal" _ -> Stdout.line "a is greater than b"I would use a wildcard for the else
The really wonderful thing about this is that it could simplify the language!!!! Combining when ..is with if ..else... along with cleaning up the alignment/noise issue with if ... else.
So really it could be when ..is AND if ... else (with alignment/noise issues) vs if matching syntax!
How about:
if
b > a ->
Stdout.line "b is greater than a"
a == b ->
Stdout.line "a and b are equal"
_ ->
Stdout.line "a is greater than b"
and
if word is
"YES" ->
Stdout.line "word is: YES"
"NO ->
Stdout.line "word is: NO"
_ ->
Stdout.line "word is not YES or NO"
If we are considering that, then why not drop bad ideaif altogether? Just use when...
Luke Boswell (Apr 19 2023 at 11:31):I like @Georges Boris idea. Though I feel strangely attached to if/then/else.
Georges Boris (Apr 19 2023 at 11:51):we already discussed some of this a while back with a few iterations on when etc and this if syntax seemed like the best of all options...
I completely understand the attachment to if/then/else but tbh, as an Elm developer, everytime I use that a small voice sounds "is this the best you can do?" haha - most of the time that is the case... especially with this conditional statements like less than / greater than etc, however, other times the high use of if/then/else, are related to a poor modeling that could be best organized through custom types (tagged unions)
Matthias Toepp (Apr 19 2023 at 11:58):@Georges Boris are you in favor of changing the current when ... is and if .. else to if .. is and (your version of) if? (as I illustrated in the last post above).
Richard Feldman (Apr 19 2023 at 12:03):else if is unavoidably part of the language; it's just a reformatting of this:
if ... then
else
if ... then
else
so the proposal is that we should have two ways to write it: else if and elif
Richard Feldman (Apr 19 2023 at 12:03):I don't think it's better to have two ways to do this than one :sweat_smile:
Richard Feldman (Apr 19 2023 at 12:05):(if we want to discuss the cond block idea, I think that should be in a separate thread!)
Georges Boris (Apr 19 2023 at 12:05):@Richard Feldman what is the downside of the proposed if statement in my previous message? like - what makes it necessary to have cond and if/else ?
Matthias Toepp (Apr 19 2023 at 12:05):@Richard Feldman
Why unavoidable?...Wouldn't that just be differnt syntax?
Richard Feldman (Apr 19 2023 at 12:06):if the language has if and else, then it unavoidably has else if
Richard Feldman (Apr 19 2023 at 12:06):because else if is just an else whose body is another if
Matthias Toepp (Apr 19 2023 at 12:06):oh, yes I see what you mean
Georges Boris (Apr 19 2023 at 12:06):@Matthias Toepp I don't think it would be if a is ... because sometimes you want to check conditions on different things, not against one a
Georges Boris (Apr 19 2023 at 12:07):in that scenario you would probably use when + guards
Richard Feldman (Apr 19 2023 at 12:07):Georges Boris said:
Richard Feldman what is the downside of the proposed
ifstatement in my previous message? like - what makes it necessary to havecondandif/else?
I think that's a separate discussion from elif and we should discuss in a different thread :big_smile:
Matthias Toepp (Apr 19 2023 at 12:12):if and combining with when is should maybe be discussed first in the other thread), in case that's the way to go, then elif is irrelevent.
Matthias Toepp (Apr 19 2023 at 12:26):https://roc.zulipchat.com/#narrow/stream/304641-ideas/topic/cond-like.20if.20syntax
Matthias Toepp (Apr 19 2023 at 18:11):I hope that elifin place of else if will be considered for Roc.
Georges Boris (Apr 19 2023 at 18:51):considering the other thread was kinda blocked, sadly - I'd still suggest something more ambitious:
if a > 1 then
"GT"
if a == 1 then
"EQ"
else
"LT"
pro
con
if if indented would start another decision tree) Richard Feldman (Apr 19 2023 at 20:00):another con is that it's an extra way to do the same thing (if / else if is still innately supported)
Matthias Toepp (Apr 19 2023 at 21:40):Georges Boris said:
considering the other thread was kinda blocked, sadly - I'd still suggest something more ambitious:
if a > 1 then "GT" if a == 1 then "EQ" else "LT"pro
- removes the diff problem of conditions having different prefixes based on position, if you want to reorder you don't have to change unrelated lines.
- less verbose
con
- it is indent-based when multi-line (another
ifif indented would start another decision tree)
My sense is that people in the Roc community love the familiarity that the conventional else if provides. Having said that.... another variation to your purpose could be using eif. which would make it only one character indented from if. It's the shortest else if equivalent that has a president that I could find for another language (Pliant) and it could be recognized as a contraction of else if.
if a > 1 then
"GT"
eif a == 1 then
"EQ"
else
"LT"
Georges Boris said:
considering the other thread was kinda blocked, sadly
it's not blocked - I'm just not convinced it's the right move for the language :big_smile:
Richard Feldman (Apr 19 2023 at 21:43):in general I'm open to hearing new ideas, I just may or may not agree with them :wink:
Matthias Toepp (Apr 19 2023 at 21:47):if a > 1 then
"GT"
ef a == 1 then
"EQ"
else
"LT"
I guess something like that cold work but has strangeness
el=(e)lese i(f)
Matthias Toepp (Apr 19 2023 at 21:54):if a > 1 then
"GT"
or a == 1 then
"EQ"
else
"LT"
if a > 1 then
"GT"
el a == 1 then
"EQ"
else
"LT"
Given if is always terminating and we can never have an if without an else. I do kinda like the repeated if before a final else.
Brendan Hansknecht (Apr 19 2023 at 22:19):We then could make else if invalid if wanted. Make it so that it requires a new line and tabling between the else and if.
Luke Boswell (Apr 19 2023 at 22:19):I think it would be cool to be able to do
if a > 1 then "GT"
if a == 1 then "EQ"
else "LT"
Brendan Hansknecht said:
Given if is always terminating and we can never have an if without an else. I do kinda like the repeated if before a final else.
Can you elaborate on your thinking about this. I understand the meaning of what you are saying but I don't quite make the connection. It seams like the condition in the middle is clearly an else if or and elif or something more than just if. I just wish I understood how you are concluding that from your premise.
Matthias Toepp (Apr 19 2023 at 22:30):Are you just saying there is a repeated if in there anyway so it does somehow make some sense to use if repeatedly?
Luke Boswell (Apr 19 2023 at 22:33):For me, I like that this makes all but the last condition aligned. Without the else that is. So achives what I think @Matthias Toepp was wanting, but removes the repeated and unnecessary else on each line.
Folkert de Vries (Apr 19 2023 at 22:34):this already works, btw
» when Num.compare 1 2 is
… GT -> 0
… EQ -> 1
… LT -> 2
…
2 : Num * # val1
and is nicer than writing out the if-then-else chain
Matthias Toepp (Apr 19 2023 at 22:39):@Folkert de Vries But that's not about boolean conditions so it's not the syntax that we are addressing. It's the if then else part we are trying to improve apon.
Matthias Toepp (Apr 19 2023 at 22:40):Everything that I've been showing as conditions is just filler and the if else syntax is the point.
Matthias Toepp (Apr 19 2023 at 22:40):Sorry if I haven't been clear about that. :neutral:
Matthias Toepp (Apr 19 2023 at 22:47):We could write
when True is
a > b -> "a is greater"
_ -> "a is not greater"
but its kind of clunky to write when True is and as pointed out in the cond thread, this causes more indentation than the if then else type of construct.
Matthias Toepp (Apr 19 2023 at 23:07):@Richard Feldman can you give us an answer if you have any interest in any of the two letter combinations of else if that I've listed above or any other two letter combination that appeals to you and will make @Georges Boris happy? of if eif or some 3 letter combination is acceptable?
Richard Feldman (Apr 20 2023 at 00:20):based on the discussion I've seen, I think the tradeoffs favor the status quo
Richard Feldman (Apr 20 2023 at 00:28):specifically I think that:
if is already syntax sugar for a subset of when, having further syntax sugar on top of that for the else sugar followed by the if sugar needs to meet an even higher bar than if itself did for justifying a new reserved keyword that's redundant with existing keywords. To be even more specific, an elif which works just like else if except that it's 3 characters shorter is not close to meeting that bar to me.elif is in Python but I don't think Elixir syntax is mainstream) eat into the language's weirdness budget, which further raises the barelse if, so none of them are at all close to meeting the bar as I see it Richard Feldman (Apr 20 2023 at 00:28):I can tell people are excited about this, but I want to be honest about how I see the tradeoffs here
Georges Boris (Apr 20 2023 at 00:45):I think I agree with you on @Richard Feldman - imo if it's not a fully minimal / case-like approach I'm +1 for the status-quo.
(I can't help myself... difference being only "3 letters short" reminded me of... Str vs String and Num vs Number :grimacing: haha I'll stop. need to know when the battle is lost)
Richard Feldman (Apr 20 2023 at 00:48):I'd be opposed to Str in addition to String fwiw
Richard Feldman (Apr 20 2023 at 00:49):but since it's actually one or the other, it's different :big_smile:
Matthias Toepp (Apr 20 2023 at 01:12):Thanks for speaking to this Richard.
Just for the record, I don't think this is just about typing three extra letters... it addresses 3 issues. 1.else if pushes five characters past the ideal of having vertical alignment of all the conditions in an if..else if block. So that breaks the flow when visually scanning the conditions vertically. 2. extra typing. 3. the noise of seeing an (arguably) unnecessary extra word obscuring the conditions , when the conditions are the key points of interest (the noise is underlined when comparing the if ..else to the cleaner when ..is syntax structure.)
elif would have been a compromise that mitigated the three issues listed above while at the same time being familiar to many people (who have seen python syntax) and while being short, it is long enough to signal its meaning.
Something like el for (el)se if would solve the issues fairly completely but is a bit stranger (and yet acceptable to me). This would result in something like this:
if b > a then
Stdout.line "b is greater than a"
el a == b then
Stdout.line "a and b are equal"
else
Stdout.line "a is greater than b"
Presumably a programmer could get used to a simpler syntax that has less typing, makes it easier to scan the conditions vertically because the conditions are vertically aligned and has less noise hiding the key elements (the conditions) even if it is slightly different from what he/she is accustomed to. It's easy to learn too, just stop typing else if after el.
I do really, really appreciate all that you and the team are doing!
Last updated: Jun 16 2026 at 16:19 UTC