Don't call it `Either`, call it `data Result e a = Ok a | Err e` (like in Elm and Rust), and call the transformer `ResultT`.
Conversation
Do NOT do this. It's an anti-pattern: it assumes the side you bind on is an "okay" result and the other is an error, which is not always the case.
2
1
Really? Why wouldn't Either be a Functor?
2
It could be two functors, it's just very unclear which. 'Right' was chosen due to silly mnemonic reasons for error handling. An hypothetical lang might allow you to bind either path with equal ease, but it would still be of use to have a type that is marked for passing errors.
2
There's no "silly mnemonics" involved at all, and no arbitrary choices. Left a because a is on the left in Either a b, Right b as it's on the right.
1
So what happens when you need to write a function to find and print the errors? Now ok and error are flipped.
1
That's definitely an issue. That's why I'd suggest having a wrapper with instances biased to the error. It's the less common case.
1
Can't say I agree with wrappers. Pointless and tiresome.
1
1
I think here you're confusing one specific use case with a simple, general type. It's "monads are not burritos, monads are not containers, ..." all over again.
1
Cool, I'm understanding your point better now.
This is kind of the problem with Haskell's nominal datatypes, canonical typeclass instances, and biased type and value abstraction in general. Pros and cons. Personally I'm a fan of just going with it an giving things meaningful names in lieu of anonymous unions.
2
1
I feel like there is work still to be done here - how to maintain the lovely compositional feeling of currying while also eliminating the need to settle on arbitrary biasing - in data structures, arguments, and instances. A non-trivial problem to solve.
1
1
Show replies