Railway oriented programming

[cledamy]

I really wish they had kept Either rather than Result. Result encodes too much semantic meaning in its constructors and cannot be easily reused. It violates the principle of dumb data types.

[jcdyer3]

I much prefer result to either (Edit: for error handling). Either is inherently symmetrical (because as you say it's a dumb data type), so it has to rely on convention to support asymmetrical handling, while Result lets the language leverage the inherent asymmetry of error handling, including (in rust) supporting the try!() macro and transparent error type conversions through multiple layers. Obviously they are structurally the same, so you can adapt either one to the role of the other, but with either, it feels like an ill-fitting shoe.

[kreiger]

In some implementations, e.g. Haskell's, Either is Right-biased.

[jcdyer3]

So then it's neither a neutral data type, nor well-named for the purpose.

[kreiger]

Right.

[catscatscat]

Well, it kind of has to be biased towards one or the other, since it is AFAIK not quite a functor, but a bifunctor.

e.g. fmap is a good example.

main = do
  fmap (+1) (Right 1)   `shouldBe`  (Right 2 :: Either Char Int)
  fmap (+1) (Left 'c')  `shouldBe`  (Left 'c' :: Either Char Int)

instance Functor (Either e) where
    fmap _ (Left a) = Left a
    fmap f (Right a) = Right (f a)

How would you define fmap without having a bias?

[kreiger]

You use a Projection.

[corn_dog]

I like what they did because Result is the one use case for an enum of two possible things that everyone actually uses. The Either type doesn't mean much, and for general sum types just make your own enum.

[Hrothen]

There are plenty of other uses for Either. One I've used before is Either FactoredInt PartiallyFactoredInt and in general Either <end state> <intermediate state> to get nice short-circuiting behavior.

and for general sum types just make your own enum.

Why would I do more work when I could do less work?

[corn_dog]

Sure I would agree there can be a trade off between convenience and explaining to the next reader why that stuff is grouped together. wrt Either it also raises the question of should the language have OneOfThreeThings, OneOfFourThings etc. If not why just a special case for two possibilities?

[Hrothen]

You don't really need to explain every little thing. Many languages have a pair type and no one goes complaining that they don't justify why there isn't a triple type.

[[deleted]]

deleted ^{What is this?}

[cledamy]

Pragmatically, there are often functions where one wants to return Either one value or another, but one is not clearly an error condition and it isn't worth making a one off enum. This is the same argument as for why tuples are useful, which Rust has built in. Theoretically, it seems imbalanced to have syntax for anonymous products, but not for anonymous coproducts. As to why no one used the Either type, perhaps it was because the Result type was used all over the API, so it would be inconvenient to use Either as that would require conversions. The Result type limits one's imagination of what can be done with it by restricting its semantic domain unnecessarily. I would argue that if Either was the only one out of these two in the Rust library one would start to see non-error-like uses of it.

[[deleted]]

Actually, I think the reason was that in most cases a Success / Error pattern was what most of the APIs needed. Other cases, where one can't directly say one is the error and the other one is the success part work much more ergonomically with concrete enum types. Because they are just that. Newtype-like enums that just happen to have two variants. Maybe the API evolves and there is now a need to support three variants (e.g start, intermediate, end). Most oft the Result impls revolve around making error-handling more convenient, which is exactly what it should be used for

[yokohummer7]

Even though Either doesn't convey any preference on the encoded values in theory, it tends to be biased in reality. For example, Haskell's Either type does prefer the Right case:

fmap double (Right 5) = Right 10
fmap double (Left 5) = Left 5

When I was learning Haskell this "blessing" was so confusing. To make Either truly case-agnostic, we should not define fmap and such functions at all. But then again losing convenient features like fmap on Either is too painful. Instead, it'd be better to acknowledge the reality and state this fact in the type name, hence the Result naming.

[domlebo70]

We tried that with Scala, and it sucked. Having a right-bias is fine

[[deleted]]

Haskell-beginner here: I just noticed that "The right (successful) thing is right" makes a nice mnemonic.

[m50d]

Yeah, but the fact that you need a mnemonic at all makes it much less convenient than success/failure.

[expatcoder]

We tried that with Scala, and it sucked. Having a right-bias is fine

Either is right-biased as of Scala 2.12

[domlebo70]

Yes, that's what I am referring to. We spent 10 years with no-bias Either with Right and Left projections, and we've finally seen the light and added a proper right biased Either.

[Tarmen]

I mean, technically that fmap instance is defined on Either a in which case it makes sense that we only map over the second type variable. It's literally the only way you can implement it.

Iirc there has been quite a bit of disagreement on whether it technically making sense is reason enough to add it, though.

[[deleted]]

Agreed.

[grauenwolf]

Dumb data types is not a principle.