Closed bergmark closed 9 years ago
I think the change to >|<
is good, the other one I think is too ad-hoc. See my inline comments.
It is a bit ad-hoc since it's not specific to ExceptT, but it's useful with orThrow
, esp since i screwed up and used >|<
instead by accident. So I'd argue it's nice to have it clearly defined to prevent confusion.
f >?< g
orThrowe = (f
orThrowe) >|< (g
orThrowe)
by the way.
We could also publish this module as a separate package (we already have that internally), but I suppose that doesn't answer the question about defining >?<
in it.
I don't see how this would prevent you from using >|<
... What you really want is <|>
and MaybeT
. With ExceptT
we really also want <|>
, but that requires a Monoid
on e
, which is why we made >|<
, but I think for Maybe
return values, you can just use MaybeT
at the use site. Is this so common it needs a special combinator?
I guess I can't tell that yet, I'll leave it out for now.
Pushed >|< changes 72b8ae89a27d6cad194ef086c74a7a7f94fc6fa3
Generalized the signature of
>|<
, the error in the first argument is never thrown so we can make that explicit.>?<
is useful in order to writef >?< g
orThrowe
wheref
andg
give aMaybe
result. I added this because I accidentally hadf >|< g
orThrowe
which will never rung
iff
fails.