Commits on Jul 27, 2016

1. Remove Applicative#pureEval …

   This probably resolves typelevel#1150, though it doesn't provide an alternative
   type class as was brought up there.
   
   @adelbertc has [gotten tripped up](typelevel#1150 (comment)) by `pureEval` defaulting to a call to `pure` with `.value` called on the `Eval`.
   
   @johnynek has also [questioned](typelevel#1150 (comment)) `pureEval` being directly on `Applicative`.
   
   @tpolecat has [raised concerns](https://gitter.im/typelevel/cats?at=5794dc4c1b9de56c0edd887a) that `pureEval` looks like it might exist as a way to inject
   side effects into a type, but that it doesn't actually make any claims
   about execution semantics or value retention, so it can't be relied upon
   to do this.
   
   I think that there could be an argument for having an instantiation method for
   a side-effect-y type (like a `Task`) that takes an `Eval[A]` and produces an instance
   that will repeat the computation given `Always`, memoize the value given
   `Later`, etc. However, I don't think that @tpolecat necessarily agrees
   with me, and I think that even _if_ this is a reasonable thing to do,
   `Applicative` probably isn't the place for it.
   
   Since several people have questioned `pureEval`, it was entirely
   untested, and I haven't heard any one argue for it staying, I'm inclined
   to remove it. If someone has a compelling example of when a non-strict
   argument can be useful for `pure`, then I may be convinced. But even
   then we should clearly document what behavior can be expected of
   `pureEval`.

   

   ceedubs committed Jul 27, 2016
   Configuration menu

   • View commit details
   • Copy full SHA for 94fcf03
   • Browse repository at this point

   Copy the full SHA

   94fcf03 View commit details

   Browse the repository at this point in the history