gleam/result: Short-circuiting guards

[silby]

In the context of a wisp web application, I found myself repeatedly looking for this function in gleam/result, not finding it, and ultimately writing it myself, with a questionable name:

fn unless(inner: Result(a, b), handler: fn(b) -> c, next: fn(a) -> c) {
  case inner {
    Ok(v) -> next(v)
    Error(e) -> handler(e)
  }
}

In context, this felt useful for running a number of fallible computations in sequence using use and just responding with an HTTP error as soon as something goes wrong in the chain.

Analogously I found myself combining result.try with result.replace_error in a couple places, i.e.:

type Error {
  Client
  Server
}
// ... 
{
  use y <- result.try(int.parse(y) |> result.replace_error(Client))
  use z <- result.try(run_a_query(y) |> result.replace_error(Server))
  Ok(pure_infallible_function(z))
}

Neither of these things is wholly satisfying to me, and having done them I wonder if I'm fighting against something else that Gleam wants me to do. It doesn't help that I'm trying to analogize in my brain to Haskell patterns but I don't think I precisely understand the comparable situation in Haskell. Are people doing stuff like this in a different way using stuff in gleam/result that makes more sense or have I genuinely found things that could plausibly be orthogonally added to stdlib?

[lpil]

Hello! Could you give some examples of when you'd use that first function? Thank you.

That second block of code looks good and usual. 👍

[silby]

Thanks for the note on the combo of replace_error and try.

So my unless is identical to the given package's ok. I think the general idea here is to reduce nesting in situations where you will return early if something is an Error and continue processing if it's Ok, but in both cases you're producing a value of some ultimate return type. This is also basically the same type signature as Haskell's either. I might pick up given's version in my own code but for now I'll keep saying unless.

Consider something like this:

fn frobnicate(username: String, id: Int) -> Result(String, Nil) {}

fn request_handler(username: String, id: String) -> wisp.Response {
  use id <- unless(int.parse(id), fn(_) { wisp.not_found() })
  use frob <- unless(frobnicate(username, id), fn(_) { wisp.response(401) })
  wisp.ok() |> wisp.string_body(frob) 
}

(One can also see here a use case for fn const(a, b) { a } but that's orthogonal.)

This also composes well with wisp helpers like require_method and require_form, since those short-circuit with a Response when requirements are not met. Compared to the "validation" pattern, where you accumulate all errors over some input before ultimately giving up, we're just bailing out in various ways depending on what we encounter along the way. And compared to chaining try, we can short circuit with some other type, rather than some consistent Result(a, b).

I think in many real situations it might be better practice to return a Result(a, b) from functions like this and do case-analysis at the end to produce your Response or whatever, but for a small wisp app it'd seem like extra ceremony.

So, I dunno, I'm clearly not making the strongest case that this is stdlib-worthy.

[lpil]

Do you have any other examples? Wisp recommends an error handling pattern that is different from the one given here, and it being the constant function in this case demonstrates this isn't the right function here, as you note.

[silby]

My most meaningful real example looks like this:

use _ <- unless(util.valid_password(new), password_error(
  context,
  "/newpass",
  _,
))

where valid_password returns a Result(Nil, PwError) and password_error sets a flash message based on the PwError and redirects.

In any case I might have more to say about this if/when I write a few thousand more lines of Gleam.

[lpil]

To me that reads as another way to write map_error, which is common and well understood in Gleam. We try not to have multiple ways to do the same thing, and we want to encourage people to have the errors constructed in the auxiliary functions rather than at the call-site where possible, so I don't think this is immediately clearly beneficial.

[silby]

Yeah that all tracks. What I've been working on is not rigorously designed and it's quite possible that when I get around to refactoring for maintainability I will forget this ever bothered me.

[inoas]

In the context of a wisp web application, I found myself repeatedly looking for this function in gleam/result, not finding it, and ultimately writing it myself, with a questionable name:

fn unless(inner: Result(a, b), handler: fn(b) -> c, next: fn(a) -> c) {
  case inner {
    Ok(v) -> next(v)
    Error(e) -> handler(e)
  }
}

https://gloogle.run/search?q=given.not maybe?

Edit: You can also specify else_return and have the return fn in the use block