MonadError with Liskov

[marcin-rzeznicki]

I think it is possible to derive an instance of MonadError[M, E1] from MonadError[M, E] if we can prove that E1<~< E. I tried to implement it and came up with:

implicit def liskovMonadError[M[_], E1, E](implicit ME: MonadError[M, E],
                                                     liskov: Liskov[E1, E],
                                                     E1: ClassTag[E1]): MonadError[M, E1] =
    new MonadError[M, E1]{
  override def raiseError[A](e1: E1) = ME.raiseError(liskov.coerce(e1))

  override def handleErrorWith[A](fa: M[A])(f: E1 => M[A]) = ME.recoverWith(fa) {
    case e1: E1 => f(e1)
  }
  override def pure[A](x: A)                                 = ME.pure(x)
  override def flatMap[A, B](fa: M[A])(f: A => M[B])         = ME.flatMap(fa)(f)
  override def tailRecM[A, B](a: A)(f: A => M[Either[A, B]]) = ME.tailRecM(a)(f)
}

The "shady" part is handleErrorWith where we need to check at runtime whether we have the right type (hence the ClassTag). I thought it would not work, but it seems to pass all the MonadError laws:

sealed trait Error
case class SubError1(s: String) extends Error
case class SubError2(s: String) extends Error

type F[A] = Either[Error, A]

implicit val ArbitraryError: Arbitrary[Error] = Arbitrary(
  Arbitrary.arbitrary[String].flatMap(s => Gen.oneOf(SubError1(s), SubError2(s))))
implicit val ArbitrarySubError1: Arbitrary[SubError1] = Arbitrary(
  Arbitrary.arbitrary[String].map(s => SubError1(s)))
implicit val CogenSubError1: Cogen[SubError1] = Cogen[String].contramap(_.s)
implicit val EqError: Eq[Error]               = Eq.fromUniversalEquals[Error]
implicit val EqSubError1: Eq[SubError1]       = Eq.fromUniversalEquals[SubError1]

checkAll("Liskov",
         MonadErrorTests[F, SubError1](liskovMonadError)
           .monadError[Int, String, Int])

Conversely, ApplicativeError might have some kind of def widenError[E1](implicit ev: Liskov[E, E1]): ApplicativeError[F, E1] .

[johnynek]

I think this it not okay. If it were okay, we would have Functor[M[F, ?]] instances on M[F, E] when we have ApplicativeError[M[?, E]].

The issue here is that any E that is not an E1, because it is in the super type, cannot be recovered. I fear the laws don't exercise that, which is why things passed.

[marcin-rzeznicki]

Yes, indeed - you cannot recover from such an error. OTOH, you cannot raise such an error either. So the only issue is with constructs such as:

sealed class E
case object E1 extends E

type F[A] = Either[E, A]

ApplicativeError[F, E1.type].handleErrorWith(Left(new E))(_ => Right(10))
// res2: F[Int] = Left(E@4c4f592f)

Whether or not this is the right thing is debatable - after all ApplicativeError[F, E1] promises to handle only E1 errors in context of F. Anyway, if this is wrong, which it very well might be, then sorry :-(

[johnynek]

you can't raise the error with this instance, but you could with another instance since someone could have that one around, no?

Just as you have done here, you have raised the error not using the instance in question, and that value, I think, should break a law, e.g. that recovering everything should not be an error in the end.

[marcin-rzeznicki]

Well, yes, unless you mean everything to be everything of declared error type .But I fully understand your objections. Thank you for the discussion. Should I close this issue?

[johnynek]

It's an interesting issue, not sure if others want to weigh in, but to me, I'd be -1 on merging this instance due to: 1. using reflection 2. a feeling that this should not pass the laws, although it currently does.

To me, the latter issue is a very interesting question. Do we have an issue with the current laws for MonadError/ApplicativeError or is it my intuition that is incorrect?

[marcin-rzeznicki]

My reasoning goes along these lines:

1. How do we treat, for instance, MonadError[Future, IOException]? Clearly, a failed Future can contain more than IOException, but for me it is useful to think of this instance as a way of saying - I can deal only with this subclass of all possible failures. Thus, it is OK to have a failed Future after recover because this implies an unexpected failure, where expected means IOException
2. Let's say we have two services: one demanding ME[F, E1] and the other - ME[F, E2], then, when they're composed together, it seems natural to satisfy the respective demands with single instance of ME[F, E = E1 | E2]. Each service can raise/recover from anything it declared it could (and only that) while the final program can safely deal with the whole range of errors.

[johnynek]

I would have thought we have a law like:

fa.handleErrorWith(_ => F.pure(())

is never finally an error. But I don't know exactly what that means. We can't test that easily. We want to say something like .onError(fn) is never called after a totally handled error.

But maybe this is wrong intuition that would break something else.