Proposal: Applicative => Monad: Call for consensus
Jan Behrens
public at magnetkern.de
Fri Jan 28 15:53:17 CET 2011
On Friday 28 January 2011 15:13:44 Jan Behrens wrote:
> On Sunday 02 January 2011 13:04:30 you wrote:
> > The patches attached to http://hackage.haskell.org/trac/ghc/ticket/4834
> > make Applicative a superclass of Monad. Default definitions are provided
> > for backwards compatibility.
>
> I looked at the Prelude of the referenced documentation in the ticket:
> http://bifunctor.homelinux.net/~bas/doc/ghc/html/libraries/base-4.4.0.0/Pre
> lude.html
>
> Would it be useful to include liftM and ap in the Prelude, so that you can
> use it as a default implementation for fmap, when defining Functor
> instances?
I have to correct myself. It should be "liftA" and "ap", as liftA is more
abstract than liftM and can thus be used as a default fmap implementation for
BOTH monads and applicative functors.
> Then you can write...
>
> instance Functor Something where
> fmap = liftM
>
> instance Applicative Something where
> pure x = ...
> (<*>) = ap
>
> instance Monad Something where
> (>>=) = ...
>
> This way you don't need to write explicit implementations of fmap and <*>
> for every monad you define.
The example would read then as follows:
instance Functor Something where
fmap = liftA
instance Applicative Something where
pure x = ...
(<*>) = ap
instance Monad Something where
(>>=) = ...
> An alternative name for liftM would be fmapMonad...
>
>
> There is a similar approach in Data.Traversable:
>
> fmapDefault :: Traversable t => (a -> b) -> t a -> t b
>
>
> However as Functor, Applicative and Monad are part of the Prelude, it might
> be useful, to include a default implementation for fmap in the Prelude.
>
>
> Regards
> Jan
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
More information about the Libraries
mailing list