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")
  })
}

[NNBnh]

I agree, case and bool.guard are 99.9% the best way to get the job done in FP language like Gleam. If-Else just doesn't useful much.

[manuel-rubio]

I have two objections about bool.guard:

First, the note should say that if you want to use side-effects or something complex, you should use lazy_guard instead (it's always good idea give a solution instead of only a limitation).

Second, the example:

let name = ""
use <- guard(when: name == "", return: "Welcome!")
"Hello, " <> name
// -> "Welcome!"

Where we changed the value of name?

[lpil]

Ah that's a mistake in the documentation. I'll get that fixed.

The other bit is due to this function being older than the lazy one so when this was written there wasn't one to recommend.

[lpil]

I've read it again while not in the middle of a long day of travelling, and this time I'm reading it correctly 😁

The example is correct. The variable name is never evaluated in that example.

[manuel-rubio]

oh! sorry, I re-read it again, you're right, both examples are right, sorry again.