Prevent `else if` · ideas · Zulip Chat Archive

Stream: ideas

Topic: Prevent `else if`

Matthias Toepp (Apr 20 2023 at 14:28):

Edit: Some interesting new solutions are being generated below but I put this out here too quickly...it was poorly thought through, read on only if you wish to discover my foolishness...

Would it be a good to have the compiler put up some kind of barrier to chaining with else if?
It could suggest that matching should be used instead, given that...

greeting =
    match True:
        num < 10 ->
            "less than 10"
        num < 100 ->
            "less than 100"
        num < 1000 ->
            "less than 1000"
        _ ->
            "it's a big number"

is much cleaner than:

greeting =
    if num < 10 then
        "less than 10"
    else if num < 100 then
        "less than 100"
    else if num < 1000 then
        "less than 1000"
    else
        "it's a big number"

so this implies changing when .. is to match..: so it sounds better to match on True. And it could also mean that True would have to be represented as True and not Bool.true.

Matthias Toepp (Apr 20 2023 at 14:35):

Note: It seems like if..then..else can't be removed altogether because single line if statements are desirable. Also possibly becauseif..then..else is more elegant comparet to pattern matching for the simplest case of working with bools.

Matthias Toepp (Apr 20 2023 at 14:43):

To express the problem with else if in words:

It pushes the condition 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.
The noise of seeing two unnecessary extra words obscuring the conditions , when the conditions are the key points of interest.

Brendan Hansknecht (Apr 20 2023 at 14:46):

Isn't this just the alternate if syntax but slightly reworded? Not saying we can't improve when to work better with guards, but I think this is identical to the alternate syntax, just with match True instead of if.

Matthias Toepp (Apr 20 2023 at 14:49):

I'm suggesting we

use a single pattern matching syntax for:
1. many-branched would-beelse ifchains
2. regular pattern matching.
And also implement a deterrent to using else if
Renaming when..is to match..:

Brendan Hansknecht (Apr 20 2023 at 14:55):

Question on the syntax: so it is essentially written in reverse form of current when ... is. What i mean by that is, in

when x is
   12 -> ...

x is always an expression and 12 is always a constant, though it is a special pattern matching constant that may bind variables.

Do you foresee any issue with merging these two syntaxes and the potential extra flexibility it adds? Theoretically, this could be used with any value, and not just Bool.true.

Matthias Toepp (Apr 20 2023 at 14:56):

i'm not meaning to suggest that...

Matthias Toepp (Apr 20 2023 at 14:57):

it's functionally the same, but changing the word choice from when..is to match..:

Matthias Toepp (Apr 20 2023 at 14:57):

maybe i'm misunderstanding something...let me read your post again.

Matthias Toepp (Apr 20 2023 at 14:58):

i see what you're saying

Matthias Toepp (Apr 20 2023 at 14:59):

yes so it is a special syntax...not as good an idea as I had hoped.

Brendan Hansknecht (Apr 20 2023 at 15:00):

For reference, the current equivalent syntax is something like:

greeting =
    when Bool.true is# Note: this could be any expression, does not have to be true.
        _ if num < 10 ->
            "less than 10"
        _ if num < 100 ->
            "less than 100"
        _ if num < 1000 ->
            "less than 1000"
        _ ->
            "it's a big number"

Brendan Hansknecht (Apr 20 2023 at 15:01):

That is why I made the comment on guards.

Matthias Toepp (Apr 20 2023 at 15:02):

yup that works but it's obviously kind of ugly

Brendan Hansknecht (Apr 20 2023 at 15:02):

for sure

Matthias Toepp (Apr 20 2023 at 15:02):

I withdraw the idea. (sorry)

Brendan Hansknecht (Apr 20 2023 at 15:03):

Always good to talk about these things. Theoretically, patterning matching could be made more flexible to support this kind of matching. I'm just not sure the ramifications of something like that.

Matthias Toepp (Apr 20 2023 at 15:03):

@Brendan Hansknecht
Thanks for setting me straight.

Matthias Toepp (Apr 20 2023 at 15:10):

Well... what if we did make it so that if the tag True was passed to the match statememt that would cause it to evaluate boolean expressions? Anyway it's probably not a good idea.

Brendan Hansknecht (Apr 20 2023 at 15:18):

That definitely would give you the feature you want. It may seem a bit out of place if it is the only special case. I have no idea what the implementation complexity would be given we now need specific bool expressions instead of patterns matching constants that may bind variables.

Brendan Hansknecht (Apr 20 2023 at 15:19):

Definitely sounds doable

Matthias Toepp (Apr 20 2023 at 15:23):

but we're back into strange territory

Matthias Toepp (Apr 20 2023 at 15:24):

...this always seems so close and yet so far!

Georges Boris (Apr 20 2023 at 19:26):

My current thought process fwiw :)

I don't think there was any downsides for the proposed syntax in the cond thread if we went for a syntax based on pattern matching. the downsides are related to the approach itself - It prevented single line usages and increased horizontal indentation.

Just think the language designers thought it was not better enough to justify not using the common if/then/else statement. I think the bar for changing this syntax is quite high since it is not seen as a problem, more like stylistic taste and some people don't really mind the verbosity since it's familiar.

So if we want to propose something new I think it needs to be a new approach entirely that either prevents serious problems with the current implementation (that we have not found yet) or gives us some super powers that would be a superset of the current feature. Even then, maybe it would still be decided to keep if as-is in addition to this new super power feature, since it doesn't hurt to have that familiar feature also available for common use cases.

Richard Feldman (Apr 20 2023 at 19:38):

yeah I don't know if we've talked about it here, but one thing I've seen discussed in the Elm community is just: why have if at all?

Richard Feldman (Apr 20 2023 at 19:38):

it's completely redundant with (in Roc terms) when

Richard Feldman (Apr 20 2023 at 19:45):

arguments for if include:

it's a nicer learner experience, because you can teach if (which is extremely easy to learn regardless of your background, including if you're new to programming) and then use that for awhile before introducing when (which is much harder to learn unless you've already used a language with that style of pattern matching)
it's super common to have conditionals based on booleans, so it's nice to be able to have a more concise syntax for that case (including single-line syntax)
subjectively, it reads better
we don't have a bunch of distracting discussions of the form "wtf this hipster language doesn't even have if"

Richard Feldman (Apr 20 2023 at 19:45):

a thread about this in Elm Discourse: https://discourse.elm-lang.org/t/if-then-else-versus-case-expressions/2273

Matthias Toepp (Apr 21 2023 at 10:39):

Something like that could be really cool!

If we adjusted the meaning of else to be the last decision
in a decision structure...

Then we could have the following:

if x < 10 then "small" else "big"

if  x < 10 then
        "small"
    else
        "big"

if  x < 10 then
        "less than ten"
    x < 100 then
        "less than 100"
    x < 1000 then
        "less than 1000"
    else
        "big"

when val is
    LessThenTen ->
        "small"
    else
        "big"

Matthias Toepp (Apr 21 2023 at 10:42):

I'll start a new thread for that last idea. I'll link back from there...

Matthias Toepp (Apr 21 2023 at 10:51):

The idea of "adjusting the meaning of else" ...
https://roc.zulipchat.com/#narrow/stream/304641-ideas/topic/adjust.20meaning.20of.20else

Last updated: Jun 16 2026 at 16:19 UTC