Repository: typelevel/cats

Issue #1316: Bring back `Applicative.pureEval` or provide equivalent
Created: 2016-08-22T13:07:50Z
I see that pureEval was removed in this commit and deployed as part of version 0.7.0.
The explanation is fine, however it needs to be brought back or it needs an equivalent. There are two reasons for it:

the point operation in Scalaz takes that parameter by name, which means Cats is no longer providing an equivalent to Scalaz's point
I understand there were concerns about controlling of side-effects, but that's not the whole story. A lazy pure can also be used for actual lazy behavior, like when building a lazy generic data-structure; think of Streaming (that was moved in Dogs) or checkout this Enumerator type that I've been building. In other words, without a lazy pure, the Applicative type becomes insufficient for problems such as building a generic lazy list like Cons[F,A](head: A, tail: F[List[A]]) type

Duplicate issue #1482: add abilitity to instantiate a non-blocking Future from MonadError
Created: 2016-12-03T15:07:02Z
When abstracting functions to return MonadError, to use Future in production and Try in unit testing, it's impossible to get an async Future from any function of the Future implementation of MonadError - either Future.successful or Future.failed is called.
In cats versions before 0.7.x. Monad.pureEval would call Future.apply, as this function was removed, there is no way to use either MonadError or Monad in an abstract way to create an async Future, which makes it hard to wrap synchronised code blocks (e.g. Java, etc.) into abstract Monads.
I would expect MonadError.catchNonFatal to show this behaviour but it's implemented as try pure(a) catch {...} (in ApplicativeError) calling Future.successful. @alexknvl suggested on Gitter to specialise this function in FutureInstances  as:
def catchNonFatal[A](a: => A)(implicit ev: Throwable <:< E): Future[A] = Future.apply(a)
This would makes sense to me. This issue is probably related to #1316.

Closing comment (2016-12-03T17:29:17Z): I think the override you suggest is correct in any case. Can you send a PR?

About the need to run an effectful computation, let's stay on #1316.

I advocate taking a FunctionK[Eval, M] along with Monad[M] personally, when
you need that.
…
On Sat, Dec 3, 2016 at 05:07 Kevin Schmidt ***@***.***> wrote:
 When abstracting functions to return MonadError, to use Future in
 production and Try in unit testing, it's impossible to get an async Future
 from any function of the Future implementation of MonadError - either
 Future.successful or Future.failed is called.

 In cats versions before 0.7.x. Monad.pureEval would call Future.apply, as
 this function was removed, there is no way to use either MonadError or
 Monad in an abstract way to create an async Future, which makes it hard
 to wrap synchronised code blocks (e.g. Java, etc.) into abstract Monads.

 I would expect MonadError.catchNonFatal to show this behaviour but it's
 implemented as try pure(a) catch {...} (in ApplicativeError) calling
 Future.successful. @alexknvl <https://github.com/alexknvl> suggested on
 Gitter to specialise this function in FutureInstances as:

 def catchNonFatal[A](a: => A)(implicit ev: Throwable <:< E): Future[A] =
 Future.apply(a)

 This would makes sense to me. This issue is probably related to #1316
 <#1316>.

 —
 You are receiving this because you are subscribed to this thread.
 Reply to this email directly, view it on GitHub
 <#1482>, or mute the thread
 <https://github.com/notifications/unsubscribe-auth/AAEJdqNEFkNkcARnJBc39UvpkElWUR1Vks5rEYWWgaJpZM4LDUVU>
 .