Case expression function

[edongashi]

Currently case expressions require an immediately evaluated argument:

case some_number {
  0 -> "Zero"
  1 -> "One"
  2 -> "Two"
  n -> "Some other number" // This matches anything
}

A proposed case _ syntax would allow declaring a pattern matching function similar to F#'s function keyword:

list.map([1, 2, 3], case _ {
  0 -> "Zero"
  1 -> "One"
  2 -> "Two"
  n -> "Some other number"
})

Which currently has to be written as:

list.map([1, 2, 3], fn(x) {
  case x {
    0 -> "Zero"
    1 -> "One"
    2 -> "Two"
    n -> "Some other number"
  }
})

You can also inject the case function into pipelines:

number
|> add(1)
|> case _ {
  0 -> "Zero"
  1 -> "One"
  2 -> "Two"
  n -> "Some other number"
}
|> io.println

I have found that "piping into" case expressions is not uncommon in Elixir. Most uses I noticed have been for error handling, but there was also a significant usage for matching lists evaluated from some pipeline. I imagine union case matching will also be common in gleam.

The contrived example below shows how we would handle a result containing a list of items.

conn
|> db.query("select * from users")
|> case _ {
  Ok([]) -> "no users"
  Ok(users) -> "some users"
  Error(reason) -> "query failed"
}
|> io.println

Rewriting the above with result.map_* higher order functions becomes rather verbose:

conn
|> db.query("select * from users")
|> result.map(fn(x) {
     case x {
       [] -> "no users"
       users -> "some users"
     }
   )
|> result.map_error(fn(_) { "query failed" })
|> io.println

[lpil]

Hi @edongashi ! Thanks for the proposal.

I would also expect this syntax to work outside of pipelines so things like this can be done:

let is_empty = case _ {
  [] -> True
  _ -> False
}

I am quite interested in what other community members think of this.

[edongashi]

I would also expect this syntax to work outside of pipelines

Correct. The list.map example highlights that.

Your example is interesting because the type inferrer may have a difficult time to figure the argument type out.

What should be done when there is not enough type information? Can this type of function have explicit type annotations?

[lpil]

Ah yes, you are right that example does show that. I missed that when focusing on the pipes.

Your example is interesting because the type inferrer may have a difficult time to figure the argument type out.

What should be done when there is not enough type information? Can this type of function have explicit type annotations?

I believe it will always have enough information to determine the types as we can currently always type fn(x) { case x { ... } }

[timjs]

I like this a lot. PureScript has similar syntax which I use often. It also works for if and operator sections, e.g. _ + 2 is short for \x -> x + 2.

[timjs]

And isn't it already the case that you can use _ to indicate the position of the argument a pipe pipes into? This would be a natural extension!

[lpil]

And isn't it already the case that you can use _ to indicate the position of the argument a pipe pipes into? This would be a natural extension!

It's more that somefun(1, _) is sugar for fn(x) { somefun(1, x) }, but there is a special case in the compiler to avoid producing extra anon functions when used with pipes