Result(a, Nil) vs Option(a)

[J3RN]

I was reading through the Result page of The Gleam Book and found Error(Nil) for "cases where we don't care about the specific error enough to want to create a custom error type" somewhat odd, but reasonable assuming that Gleam didn't have an Option type. However, I discovered that gleam/option does exist.

Given that, my question is: Are there cases where one should use Result(a, Nil) instead of using Option(a)?

[edongashi]

I also found that the list module uses Result(a, Nil) instead of the more natural Option(a) for functions such as find_map and many others.

I suppose this is for convenience to allow binding returned values with try. There should be a more natural way to bind Option, otherwise the non-idiomatic Result(a, Nil) will be abused.

[lpil]

Hello! Result is to be used for operations that may not succeed, so it is the idiomatic return type in Gleam. Option is for a value that may or may not be present, not for operations that could fail.

[edongashi]

Result is to be used for operations that may not succeed

I wouldn't consider looking for an item in a list and not finding it a "failure". There is either Some element in the list that matches a condition or None.

In F#, the equivalent list functions use option.

It's fine either way IMO, though making Result(a, Nil) compete with Option(a) creates redundancy. Are there any plans to make try work with Option as well?

[lpil]

I wouldn't consider looking for an item in a list and not finding it a "failure". There is either Some element in the list that matches a condition or None.

These are the semantics in Gleam. "Did you manage to get the Nth value from this array?" "No, I was unable".

It's fine either way IMO, though making Result(a, Nil) compete with Option(a) creates redundancy.

It is the inverse! In Gleam Result is always used. To use result sometimes and to use option other times produces redundancy. Gleam is more consistent than F# in this way.

[edongashi]

In Gleam Result is always used.

I see. What does Gleam consider valid uses of Option? Nullables in structs and possible missing input parameters?

[lpil]

Hello! Good question, thank you.

Result is to be used for operations that may not succeed, such as attempting to retrieve an entry from a data structure. Other languages use a mix of option and result for this scenario, but Gleam always uses result. This consistency means we have to do less converting between the two types and our special try syntax works with all fallible functions.

Later we will have better documentation for this, what we currently have is a bit basic while the core language and tooling is being worked on.

[swizzard]

This strikes me as pretty unintuitive: both Haskell and Rust use their equivalent of Option (Maybe and Option, respectively) when retrieving values from a list or map. Having Gleam be consistent with other strongly typed functional languages would reduce cognitive friction for users coming from those languages. The way Rust's Result or Haskell's Either are used is when there's "something else" involved, usually an error or separate branch. I'm also personally somewhat uncomfortable with the use of `Nil` in this context because of typing implications: is `Nil` an inhabitant of every type (like `undefined` in Haskell)? Is `Result(a, b)` secretly desugared into `Result(a, b | Nil)`? Neither seem terribly sound or, again, intuitive. Lastly, for whatever it's worth, `Result(a, Nil)` is isomorphic to `Option(a)` from a category theory perspective--it's trivial to implement functions that translate between them.

…

On Tue, Sep 14, 2021 at 9:19 AM Louis Pilfold ***@***.***> wrote: I wouldn't consider looking for an item in a list and not finding it a "failure". There is either Some element in the list that matches a condition or None. These are the semantics in Gleam. "Did you manage to get the Nth value from this array?" "No, I was unable". It's fine either way IMO, though making Result(a, Nil) compete with Option(a) creates redundancy. It is the inverse! In Gleam Result is *always* used. To use result sometimes and to use option other times produces redundancy. Gleam is more consistent than F# in this way. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1265 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOSJHTPGOAVYCXDEJ4DBX3UB5KYHANCNFSM5D4LP5TQ> .

-- .

[lpil]

Please don't confuse something being familiar with something being intuitive. While both important they are not the same thing.

This debate is a question of whether failure to get a value from a structure should return a null value (as in F#, JavaScript), or whether it is an error (Gleam, Python). Both are equally correct so we must look to other aspects to decide what is best.

Gleam does not draw from category theory and does not have any form of interfaces, but it does have special sugar for the result type, so result makes more sense for Gleam.

The Nil value may be replaced with a generic compostable error type similar to that found in Rust or Go. See the Snag library and other discussions for some early ideas.