Hacker News Reader

Comment by bjz_ | Hacker News Reader

It's nice to see that they have replaced Either with Result[0]. I wonder if Rust's Result type[1] was the inspiration? (not sure if there is prior art)

[0]: http://elm-lang.org/blog/announce/0.14.elm#making-error-hand...

[1]: http://static.rust-lang.org/doc/master/std/result/index.html

View on HN

I started looking into Rust again while picking the term "union type" because of their choice to use the term "enum". I ran into the Result type in some code I was reading and it just made so much more sense to me as a new person learning the language. Basically, it made it self-evident to me that "a library for error handling should be named with error handling in mind." You will also see a Result type in some Haskell libraries so it's not unprecedented there.

I also got tired of explaining "the good result goes in Right, because it's 'Right'" like I'm endlessly telling a bad dad-joke.

Yeah, we used to have an Either type in the Rust std, but it was pretty much never used because we had Result.

It's possible, but it's really just a name change. And the `Either` monad is used almost entirely for error handling anyway, so Result is a name that many Haskell/Elm users could come up with on their own.

But the variants being named `Ok` and `Err` match Rust's definition as well, which is why I'd like to second bjz's question as to whether there's some lineage behind this convention.

I decided to do some archaeology of my own.

Here's the first instance of what would become Rust's `Result` type (Oct 28 2011): https://github.com/rust-lang/rust/commit/c1092fb6d88efe51e42...

Note that the type is called `t` since the convention at the time was to name the primary type of a module `t` and then refer to the type as `modulename::t` (shows how far we've come, eh?). At this initial stage the variants are named `ok` and `error`. Also note that at this point in history Rust had had an `either` type for a while (https://github.com/rust-lang/rust/blob/c1092fb6d88efe51e42df...), which would later be removed as Result gained more traction.

Here's the commit where the `error` variant is renamed to `err` (Oct 28 2011, so the same day): https://github.com/rust-lang/rust/commit/2b62a80202e2855d47f...

Here's the first instance of `std::result` being mentioned in the mailing list (Nov 14 2011): http://article.gmane.org/gmane.comp.lang.rust.devel/891

Where the type itself is renamed to `result` (Mar 13 2012): https://github.com/rust-lang/rust/commit/b968c8e6cd362567bf0...

Where the type and variant names are capitalized in accordance with the current style guide (Aug 26 2012): https://github.com/rust-lang/rust/commit/0c6e470a257fc546555...

So this convention may very well have originated with Rust.

Also interesting to note in the context of the union type discussions below is the use of the `tag` keyword as opposed to the current `enum` for declaring tagged unions.

I always did like `tag`, but I think that's a fight for another year. :)

At one point we were trying to name every part of a union type in Elm. Calling things "tags" instead of "constructors" seemed quite nice, but ultimately, it seemed like we couldn't get the perfect name.

"Result" is a pretty opaque name: any value or type can be called a "Result", really. "Either" at least hints to the fact that it is either-this-or-that.

"Either" is IMO a nice counterpart to tuple types: one is a generic sum, the other is a generic product. People could complain that a tuple of ints are less descriptive than just using a constructor with a more descriptive name - like "Pair" or "Coordinate", depending on its intended application.

Having a specialized type for error handling makes sense, though.

It doesn't seem scalable though, because it only works for two types. It would be better to have some sort of structural union type (like Ceyleon).

But it's defined as 'Result error value', which means you can just make 'error' a union type, and now you have multiple kinds of exceptions. When you specify an error type, you're basically specifying all the types of exceptions that the evaluation can raise.

But it would be less descriptive from an API point of view. Which type is the return value? Of course we are now in the land of hypotheticals.

Reply on news.ycombinator.com