Could if statement makes sense here?

[manuel-rubio]

I was reading code like this:

  case list.length(events) >= tracker.limit {
    True -> Error(TooIntense)
    False -> Ok(IntensityTracker(..tracker, events: events))
  }

Because I came from Erlang and Elixir, I could consider something that's clear to keep it as Erlanger but maybe it could be simplified (my alchemist is yelling about it! :-D ):

  if list.length(events) >= tracker.limit {
    Error(TooIntense)
  } else {
    Ok(IntensityTracker(..tracker, events: events))
  }

Of course, it should be useful and used for Bool evaluations, what do you think?

[inoas]

Personally I'd like an if/else that:

• is an expression obviously
• enforces explicit else
• only takes boolean (no boolish) expressions
• short cuts
• does not have any elseif feature

if foo() && bar() && quux() {
  True
} else {
  False
}

...goes into else after foo() returned False.

That being said, except for reserving if and else as keywords this can be added quite easily down the line, and the gains are small I guess, so IMHO this is quite low prio.

[lpil]

I think if/else could be a possibility in future. Let's see how we get with use to start as it can do the same thing.

[inoas]

use can short-circuit? (or rather I can built short circuit logic in a terse way with use?)

[lpil]

Yes, check out bool.guard

[inoas]

I meant this:

/// Note that unlike in procedural languages the return value is evaluated
/// even when the predicate is False, so it is advisable not to perform
/// expensive computation there.

[inoas]

I think having if/else helps with strangeness budget. We could even support if/elseif/else by throwing a specific compiler error that says to use case?

[tryoxiss]

This! I think that the case is clearer and adding multiple ways to do the same thing would go against the languages stated goals, but having an error that shows how to turn it into gleam syntax (with case) would be helpful for new people without going against the goals (simillar to how panic(msg) gives an error and says to use panic as msg).

[lpil]

Clever! Could you make an issue for that, please?

[tryoxiss]

Sure, created #3572 !

[timjs]

What about adding a multi-way conditional expression, like if in Erlang, cond in Elixir and multi-way if in Haskell?

Currently you'd write:

case c1 {
  True -> e1
  False -> e0
}

(38 characters).
With an if-then-else this would become:

if c1 {
  e1
} else {
  e0
}

(28 characters).
I'd say something like:

when {
  c1 -> e1
  else -> e0
}

(32 characters) would be readable and easily expandable.

Take an example with more boolean tests:

case c1 {
  True -> e1
  False -> case c2 {
    True -> e2
    False -> e0
  }
}

(80 characters).
With if-then-else this would become:

if c1 {
  e1
} else { if c2 {
  e2
} else {
  e0
} }

(52 characters when formatted without an extra indent).
With multi-way branching:

when {
  c1 -> e1
  c2 -> e2
  else -> e0
}

(42 characters).

This would:

• be an expression obviously
• enforce explicit else
• only take boolean (no boolish) expressions
• short cut
• take multiple branches

Another benefit: using this multi-way if, the right-right-hand side of the arrows can be single expressions in most cases, and block expressions only when needed, like in Gleam's case expression. The if-then-else forces block expressions for both branches.

[inoas]

if is already reserved, unlike when, where, cond, else, or

[timjs]

I realised I didn't explain why I think if-then-else doesn't fit Gleam. Let me try to elaborate.

Gleam is an expression based language. One possible kind of expression is a block expression, which evaluates to the last expression in the block. This is consistent throughout Gleam's language constructs:

let x = 1 * 2  // short
let y = {      // long
  let a = f()
  Some(a)
}
let z = case y {
  None -> 42   // short
  Some(v) -> { // long
    use w <- g()
    v * w
  }
}

Because of this, I think an if c { e1 } else { e2 } syntax doesn't fit Gleam because, as I mentioned earlier, it forces you to always use a block, even for short expressions:

let e = if is_some(y) { // could be short...
  42
} else {
  use w <- g()
  37 * w
}

Obviously, YMMV, but I don't like this inconsistency.

One could mitigate this, by introducing an if c then e1 else e2 expression like StandardML/OCaml/F# like this:

let e = if is_some(y)
  then 42
  else {
    use w <- g()
    37 * w
  }

Problem is, Gleam uses curly braced syntax C-style syntax, where a then keyword is not common. So doing above, would trip over users coming from JavaScript, Rust, etc. (and even Python, which doesn't have a then either). Combining (imperative) curly-braced syntax with (functional) expression based semantics is a challenge...

That's why I think something like cond as found in Elixir/Scheme/Racket fits a functional expression based language like Gleam better. It also resembles the already used case construct, but then evaluating predicates top-to-bottom instead of pattern matching top-to-bottom.

let e = when {
  is_some(y) -> 42 // short
  True -> {        // long
    use w <- g()
    37 * w
  }
}

(With any keyword/underscore/... signalling the last branch is the default branch and is always evaluated in in the end.)

But, in the end, I can understand that an argument "this is more natural and recognisable for the intended user base" overrules the argument "this fits the value that everything in the language is an expressions, and longer expressions are grouped in a block".

[inoas]

I don't see the issue with if condition {body} else condition {body}

if {a && b} {
  c
} else {
  d
}

... looks fine to me.
However I also like cond/when as it can be a very concise and powerful multi way switch. I want to see that eventually tbh.

[bentomas]

I love this when syntax. It feels like it matches case syntax but in a usefully different way, is very flexible, and can be super concise or more verbose. I do wonder if you avoid some of the "strangeness" if you just call it if...

if {
  c1 -> e1
  c2 -> e2
  else -> e0
}

if {
  c1 -> {
    e1
  }
  else -> e0
}

(this is starting to look a lot like erlang's if but not limited to guards. could just skip the else and go all in on that syntax and use True, at least it has precedent and would have some familiarity)

one thing i like about this over an else if is that it makes for cleaner diffs in version control when adding new clauses.

the other thing i don't like about if condition {body} else condition {body} is that in gleam the else wouldn't be optional, right? since it is an expression, doesn't it always have to return a value? so in let x = if cond {body} nothing would be returned if the cond is false. yet the syntax would sure imply that the else is optional. at a minimum, it is optional in other languages, so new users would get tripped up on that.

[inoas]

I really like the idea of support if like that, except for the curleys

i'd love something like this:

if c1 -> expression1
   c2 -> expression2
 else -> expression0

or if the body is longer

if c1 ->
     expressionexpressionexpressionexpressionexpression1
   c2 -> e2
 else -> e0

[human154]

Isn't this currently possible and still more concise than use and bool.guard?

  case any_irrelevant_value {
    _ if x < 10 -> io.println("small")
    _ if x < 100 -> io.println("medium")
    _ -> io.println("large")
  }

we could allow this at least:

  case _ {
    _ if x < 10 -> io.println("small")
    _ if x < 100 -> io.println("medium")
    _ -> io.println("large")
  }

Allowing the use of the underscore (as shown above) in place of needing to supply an irrelevant value... it's a consistent syntax.

[lpil]

That works, but guards only permit a very limited set of expressions in them. You can't call a function, for example.

[human154]

Why are guards limited? ...its not obvious to me why this would be handled differently from an if else branching structure.

[lpil]

The virtual machine restricts guards for performance reasons.

[human154]

Dropping more syntax:

[human154]

  case {
    if x < 10 -> io.println("small")
    if x < 100 -> io.println("medium")
    _ -> io.println("large")
  }

[inoas]

I don't like this because I'd assume I can use guards on the right side too

[human154]

  case {
    x < 10 -> io.println("small")
    x < 100 -> io.println("medium")
    _ -> io.println("large")
  }

This would be roughly equivalent to kotlin's when:

    // Kotlin
    // "when" can be used as an alternative to "if-else if" chains.
    val i = 10
    when {
        i < 7 -> println("first block")
        fooString.startsWith("hello") -> println("second block")
        else -> println("else block")
    }

    // "when" can be used with an argument.
    when (i) {
        0, 21 -> println("0 or 21")
        in 1..20 -> println("in the range 1 to 20")
        else -> println("none of the above")
    }

I think these possibilities are cleaner than if..else if..else and more consistent with existing Gleam syntax. There is less syntactic keyword noise, conditions are placed front and center, and the conditions get vertical alignment (which they don't with if then else because if is shorter than else if).

[human154]

This is currently valid syntax:

case x < 10 {
    True -> "small"
    False -> 
case x < 100 {
    True -> "medium"
    False -> 
case x < 1000 {
    True -> "large"
    False -> "extra large"
}}}

It reads nicely.

[inoas]

if it was formatted like this maybe >:D

[NNBnh]

I love Gleam dedication for minimalism to only have one type of flow control: case. But I just wandering and try to play devil's advocate, so I make If-Elif-Else in Gleam:

import gleam/option.{type Option, None, Some}
import gleam/io

fn if_then(requirement: Bool, consequence: fn() -> a) -> Option(a) {
  case requirement {
    True -> Some(consequence())
    False -> None
  }
}

fn elif_then(value: Option(a), requirement: Bool, consequence: fn() -> a) -> Option(a) {
  case value, requirement {
    Some(value), _ -> Some(value)
    None, True -> Some(consequence())
    _, _ -> None
  }
}

fn else_then(value: Option(a), consequence: fn() -> a) -> Option(a) {
  case value {
    Some(value) -> Some(value)
    None -> Some(consequence())
  }
}

pub fn main() {
  if_then(False, fn() {
    io.println("Foo")
  }) |> elif_then(True, fn() {
    io.println("Bar")
  }) |> else_then(fn() {
    io.println("Baz")
  })
}

[danielytics]

What about adding a functional ternary to go alongside guard?

bool.if_else(when: Bool, true: a, false: a) -> a

It would have a similar use to guard except the else (false) isn’t lazy like in guard.

I personally already use such a function for cases like if_else(value > threshold, use_value_a, use_value_b)

There is also some prior art for such a function, so it wouldn’t really take from the weirdness budget:

• R, Julia, and MATLAB have ifelse(c, a, b)
• Pine Script has iff(c, a, b)

The implementation would simply be:

pub fn if_else(when condition: Bool, true true_val: a, false false_val: a) -> a {
  case condition {
    True -> true_val
    False -> false_val
  }
}

[lpil]

What's the advantage of this over a case expression?

[danielytics]

That’s a question for this entire discussion, right? I mean, the question about adding if-else at all is whether there’s an advantage over case. I think in general, case is the more flexible and useful tool and adding a functional-ternary isn’t necessary, however guard exists and (in my opinion, others may disagree) a function ternary makes some code terser and more readable.

Where I personally use it is code like this:

let healing_rate = if_else(healing_buff, buffed_healing_rate, passive_healing_rate)
let stamina_recovery_rate = if_else(stamina_buff, buffed_stamina_rate, passive_stamina_rate)

Where many such selections (for different rates and values —and types) are made in succession, this is easier to read and maintain than using case:

let healing_rate = case healing_buff {
  True -> buffed_healing_rate
  False -> passive_healing_rate
}
let stamina_recovery_rate = case stamina_buff {
  True -> buffed_stamina_rate
  False -> passive_stamina_rate
}

I mean, this is a contrived example and there are other better ways this could be done, and you could certainly make a case that this explicit code is more readable (in this example I think case us easier to understand at a glance, even if more verbose…), but my point is simply that it quickly becomes a lot of repeated code and at some point longer code is harder to read simply because there’s a lot of it, even if each individual part is simpler in isolation.

In my case, I made a little helper function that does this. It’s not a big deal.

I see it the same way I see bool.to_int or even bool.guard: trivial technically-unnecessary functions (it’s two seconds to define them yourself, if needed), but still nice to have provided in the standard lib.

I don’t feel strongly about it either way, though. I’m suggesting it only because it seems to fit with guard and other languages provide it.

[lpil]

I find the function one harder to read, but also they're different. The function one performs worse as it evaluate both arguments.

If it was like this it would be closer, but there's still some overhead

let healing_rate =
  if_else(healing_buff, fn() { buffed_healing_rate }, fn() {
    passive_healing_rate
  })
let stamina_recovery_rate =
  if_else(stamina_buff, fn() { buffed_stamina_rate }, fn() {
    passive_stamina_rate
  })

Note I have run the formatter on this code.

I don't think this is any easier to understand, and one of Gleam's design goals is to not have multiple ways to do the same thing. I don't see any advantages to this presently.

bool.to_int

Good point. I will deprecate this now.

[danielytics]

if think in situations where you want them to be lazily evaluated, case comes up the clear winner — once you wrap each argument in a function, case is cleaner and shorter. The benefit only exists when you’re switching between two simple values.

Like I said, the example is contrived, but I do find a helper function like this made my code more readable because it let me create a series of one-liners. But also, I’m not sure it adds enough value to include because I think it’s uses are very limited and it’s so easy to just create if desired, and the only reason I suggested it is because other languages deemed it useful to include and it seemed to fit with the discussion and similarity to guard. I won’t be upset if you say “ok, but no thanks”.

Good point. I will deprecate this now.

I didn’t mean it shouldn’t exist 😅 I mentioned it as an example of existing trivial functions that might still be beneficial to have included, sometimes. I haven’t looked very hard, but I assume there are many trivial functions in stdlib and I think being trivial isn’t enough to say they don’t have a place there.

one of Gleam's design goals is to not have multiple ways to do the same thing

Yes, absolutely. There are already cases like guard where there are multiple ways to do the same thing, but they have a much more general set of use cases and clearer value. So, after hearing your thoughts and thinking about it more, I think gleam shouldn’t include this and personally I don’t think an if-else expression really fits either. Also it does seem like the prior art is perhaps solving a different problem (In R and presumably Julia and MATLAB, it seems it can be applied over a sequence of conditions, like a list.map, not only single conditions).

So, sorry for the noise 😅