I'm trying to implement my own Result type (and yes, I'm aware you can abuse Either for this :-) ) but doing something as (seemingly?) simple as implementing a Functor instance was surprisingly difficult.
Without knowing your final use case are Bifunctors what you are after (https://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Bifunctor.html)? I used them when I wanted to fmap Left to convert errors to other errors. -Sumit
On Sat, Mar 3, 2018 at 11:34 PM, Sumit Raja
I'm trying to implement my own Result type (and yes, I'm aware you can abuse Either for this :-) ) but doing something as (seemingly?) simple as implementing a Functor instance was surprisingly difficult.
Without knowing your final use case are Bifunctors what you are after (https://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Bifunctor.html)? I used them when I wanted to fmap Left to convert errors to other errors.
No, they provide too much power. [I don't want to do anything more than die on the first error although I may add support for multiple errors later.] And I want to do this myself! No doubt, once I'm (far) more familiar with Haskell I'll be able to use things like Either and BiFunctor but right now they are just a step too far. I get lost in a forest of "weird" operators. :-) The purpose really is to work on something I fully understand (a Result type) and then see what I need to do in Haskell to support that. I just felt that the logical/intuitive type (at least to me) is "Result success failure" (it's the success value I really care about, after all) but that does not work with Functor (or Applicative, or Monad), AFAICT. So the order ("failure" first) seems to be forced on me. So be it. P.S. The second line in the Data.Bifunctor documentation made me chuckle: "Intuitively it is a bifunctor where both the first and second arguments are covariant.". Intuitive? Really? :-) ;-)
participants (2)
-
Hilco Wijbenga -
Sumit Raja