Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This probably resolves #1150, though it doesn't provide an alternative
type class as was brought up there.
@adelbertc has gotten tripped up by
pureEval
defaulting to a call topure
with.value
called on theEval
.@johnynek has also questioned
pureEval
being directly onApplicative
.@tpolecat has raised concerns that
pureEval
looks like it might exist as a way to injectside 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 anEval[A]
and produces an instancethat will repeat the computation given
Always
, memoize the value givenLater
, etc. However, I don't think that @tpolecat necessarily agreeswith 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 entirelyuntested, 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 eventhen we should clearly document what behavior can be expected of
pureEval
.@non I believe that you originally added
pureEval
as part of yourStreamingT
work. Do you have any thoughts on this?