use can be quite confusing

[sporto]

I really like the concept of use as a way to have a general way to reduce nesting and boilerplate.
However I was just upgrading a library (removing try). And I found use quite confusing to use.

Here are common errors I hit:

Common error 1 - forgetting to use result.then

pub fn do_something() -> Result(Int, String) {
  use answer <- get_answer()

  Ok(answer + 1)
} 

error: Incorrect arity
    ┌─ /Users/sebastian/Source/sporto/gleam_qs/src/qs.gleam:169:3
    │
169 │ ╭   use answer <- get_answer()
170 │ │
171 │ │   Ok(answer + 1)
    │ ╰────────────────^ Expected no arguments, got 1

The error for use is puzzling because you cannot see the unwanted extra argument in that line.

Common error 2 - using pipe

pub fn do_something() -> Result(Int, String) {
  use answer <- get_answer() |> result.then

  Ok(answer + 1)
} 

As is common to use pipes everywhere, this ^ makes a lot of sense

error: Type mismatch
    ┌─ /Users/sebastian/Source/sporto/gleam_qs/src/qs.gleam:169:33
    │
169 │   use answer <- get_answer() |> result.then
    │                                 ^^^^^^^^^^^

Expected type:

    fn(Result(a, b), fn(a) -> Result(c, b)) -> Result(c, b)

Found type:

    fn(Result(Int, String)) -> d

This error is also very hard to understand as there are lot of types involved.

The proper way is

pub fn do_something() -> Result(Int, String) {
  use answer <- result.map(get_answer())

  answer + 1
} 

try was quite straightforward, but unfortunatelly use is not. You really need to understand what is going on, it is quite hard to figure it out from the errors.

So ideas

• Could the error messages be improved? Maybe suggest correct usage?
• Or have some syntax sugar that will make this less error prone?

[lpil]

Better error messages are something we want for sure! Currently it's syntactic sugar, in future we're likely to have a dedicated compile path for it.

Or have some syntax sugar that will make this less error prone?

What did you have in mind?

However I was just upgrading a library (removing try).

If you use the version of Gleam that deprecated try you can run gleam fix and it will automatically do this for you.

[sporto]

I'm not clear what happens when you do

use answer <- get_answer() |> result.then

Could this maybe be allowed by tweaking operators precendence, is there such a thing in Gleam?

[lpil]

That isn't possible because in Gleam a pipe isn't syntactic sugar, you can't apply a syntax transformation to a pipe and always get the correct result, you need to look at the type of the function being piped into.

To do this use would need to have a special case for pipes, and it would either need to replicate the logic of how pipes work, or only work for a subset of pipes. To make matters more complex this would also mean that certain use expressions would stop working if rewritten using the pipe syntax as the rules would be inconsistent between the two ways of calling functions in Gleam.

Lastly, from a code legibility point of view I think the examples given where the flow control is hidden at the bottom of a pipeline is much less clear than when it is front and centre. Keeping the most important function by the keyword helps the reader quickly understand what the expression does.

[timjs]

Lastly, from a code legibility point of view I think the examples given where the flow control is hidden at the bottom of a pipeline is much less clear than when it is front and centre. Keeping the most important function by the keyword helps the reader quickly understand what the expression does.

I like this argument, indeed one sees upfront that try is being used for example.

That isn't possible because in Gleam a pipe isn't syntactic sugar, you can't apply a syntax transformation to a pipe and always get the correct result, you need to look at the type of the function being piped into.

However, I don't understand this. Why is type info needed? I thought pipes simply place the lhs as the first argument of the expression on the rhs, except when using _, then it replaces that argument. But you don't need type info for this. Could you explain why it is more complicated?

[lpil]

I thought pipes simply place the lhs as the first argument of the expression on the rhs, except when using _, then it replaces that argument.

It will attempt to rewrite a |> b(c) to either b(a, c) or b(c)(a) and use whichever one is correct according to the type of b.

[timjs]

I did not know it takes currying into account, nice! Is that somewhere in the docs?

Out of curiosity: is curried pipe used a lot?

[lpil]

It's documented, and it's very common. Now I look it seems that argument insertion pipe is undocumented in the tour, heh 😁

[sporto]

| What did you have in mind?

I don't have any good ideas at the moment. I was looking at how OCaml where they have several keyword/operators combinations like let* let+, but that is also quite confusing for someone new to the language.

I was also looking at Unison abilities, where you can define your handlers. Something like defining your own use. Maybe there is something to that.

But given that Result is such a common return value, maybe it could be priviliged in the language again, like it was with try. e.g.

use_result answer <- get_answer()

[lpil]

I was also looking at Unison abilities, where you can define your handlers. Something like defining your own use. Maybe there is something to that.

We deliberately don't use overridable operators as they are less clear to the reader than writing the names of functions.

In this code we can tell that the implementation is result.map

use x <- result.map(load())

While in this code it is less clear where the implementation is defined, we would have to scroll to the top of the file to read the imports.

use x <- load()

Worse, because which use function is used cannot be specified on a per-case basis it means that use becomes much less expressive than it is today, and degrades to being as powerful as Haskell's do syntax or one of OCaml's let operators.

This code wouldn't be possible, for example:

pub fn handle_request(
  request: Request(BitString),
  config: Config,
) -> Response(BitBuilder) {
  let request = utility.method_override(request)
  use <- rescue_errors.middleware
  use <- static.serve_assets(request)
  use <- print_requests.middleware(request)
  use db <- database.with_connection(config.database_path)
  use user <- auth.get_user_from_session(request, db, config.signing_secret)

  router(request, user, db)
  |> response.prepend_header("x-robots-tag", "noindex")
  |> response.prepend_header("made-with", "Gleam")
  |> response.map(bit_builder.from_string_builder)
}

[sporto]

I was imagining that you would define handlers using different names, not overriding use. Something like

use_option answer1 <- get_optional_answer()
use_result answer2 <- get_answer_result()
use user <- auth.get_user(...)

Having said that, mostly I'm hoping for a terser way to handle results, as result is so common.

[lpil]

There's more than one function one would use with use and options or results, so it would need to be something like this:

use_option_map x <- y

Which is what we have today, with slightly different syntax:

use x <- option.map(y)

Having said that, mostly I'm hoping for a terser way to handle results, as result is so common.

The current syntax is more concise than the syntax you've suggested there:

// Proposed
use_result answer2 <- get_answer_result()

// Current
use answer2 <- try(get_answer_result())