Reputation: 4771
What is the difference between return
and pure
from Control.Applicative
? It seems that I can use pure
even at the end of a do
block?
So is there any situation where one should be preferred over the other (besides that everyone expects a return
at the end of a do
Block)?
Upvotes: 52
Views: 8906
Reputation: 144206
The Applicative typeclass was added after Monad
and historically the Monad
class has not been a subclass of Applicative
. This was changed fairly recently in the Applicative-Monad-Proposal
and this means that return a
should be equivalent to pure a
for every Monad
instance.
There is a proposal to move return
out of the Monad
class and make it an alias for pure
.
Therefore when dealing with a Monad
you should always be able to use pure
instead of return
. You cannot go the other way however since pure
has a more general type than return
since it only returns an Applicative
. For example the following
wontCheck :: Applicative f => f Int
wontCheck = return 4
won't type check since return
requires f
to be a Monad
.
Upvotes: 31
Reputation: 15605
In GHC 7.8 and before, Applicative
was not a superclass of Monad
. It was even possible for a Monad
instance to not have an Applicative
instance. There was, however, an expectation that pure
and return
should have the same behavior for types that are instances of both.
In GHC 7.10, due to the Functor-Applicative-Monad Proposal, Applicative
is now a superclass of Monad
(class Applicative m => Monad m
) and it is now a rule that pure
and return
must be the same for all Monad
instances. In fact, the default implementation of return
is now pure
, as seen in the source on hackage.
pure
might be preferred to return
because it does not incur a Monad
constraint, only an Applicative
constraint, thus making the function more general. return
might be preferred to pure
in do notation because of historical precedent, but pure
could be used to exactly the same effect.
Upvotes: 67