pureEval vs a typeclass

[johnynek]

Apologies if this was discussed, but I wonder why pureEval was added to Applicative vs something like:

trait ApplicativeEval[F[_]] extends Applicative[F] {
  def pureEval[A](p: Eval[A]): F[A]
}

with the law that Eq[F[A]].equiv(pureEval(e), pure(e.value))

Seems like making that always present but by default forcing .value it removes the ability of the caller of pureEval to know if value is called immediately or not. With a new type, it would not be optional laziness, it would advertise true laziness support.

Maybe this is not a super meaningful distinction (unlike tailRecM which can be implemented in a non-tailrecursive way with flatMap), but still it seemed easy enough to signal at the type level.

[ceedubs]

In case it's of any interest, today on Gitter @tpolecat had me questioning pureEval.

[tpolecat]

What does "true laziness support" mean? Would it be a guarantee that the Eval is forced always (and only) on ap? We can't state that as an identity because it would only be observable in the presence of side-effects (including non-termination). So I take this as a hint that it's probably not a real abstraction.

[johnynek]

@tpolecat yeah, I think that's right. You could test that by using a var that you increment in an Eval.Once and verify it has not been incremented after pureEval.

Is it a "real abstraction"? I don't know, but I know some M[_] do support laziness (for instance twitter's Future), which can have some implications for resource or stack safety.

That said, I am wondering if we just want to have FunctionK[Eval, M] rather than a typeclass for FromEval[M].

[adelbertc]

Another concern I ran into yesterday was that pureEval defaults to calling pure with eval.value - if anything I feel this should be the other way around, that pure calls pureEval with Eval.now(a).

The specific situation I ran into is writing an IO type with a MonadCatch type class. One of the laws of MonadCatch involves "throwing" an exception which relies on a lazy pure. When testing the instance for say, OptionT[IO, ?], the test failed because while IO overrode pureEval, OptionT did not and so the test failed before even having a chance to reach IO.

Some discussion on Gitter happened here: https://gitter.im/typelevel/cats?at=5796a24600c8ebdd0e239982