Applicative and Functor
ashley at semantic.org
Mon Mar 6 00:53:02 EST 2006
In article <20060305233414.GA8685 at soi.city.ac.uk>,
Ross Paterson <ross at soi.city.ac.uk> wrote:
> so I would also need
> instance Functor ((->) a)
> but where should it go? (The same instance occurs in
> Control.Monad.Reader, but that could be removed.)
The Prelude is to obvious place, since that's where both Functor and
(->) are introduced.
> > There may also be a case for a class with ap (<*>) but not return
> > (pure), which might better be called "Applicative".
> Do you have both instances and clients for this interface?
Well, no, but ap gives you (>>) (I'd forgotten this earlier):
ap :: Applicative' => f (a -> b) -> f a -> f b
(>>) :: f a -> f b -> f b
fa >> fb = ap_ (fmap const fb) fa
Of course one must be careful about which argument gets "executed" first:
ap_ :: Applicative' => f (a -> b) -> f a -> f b
ap_ fab fa = ap (fmap (\a ab -> ab a) fa) fab
ap and ap_ have the same type signature, but are different for such
things as IO.
> And can an associativity law even be stated?
Yes, (p >> q) >> r = p >> (q >> r)
> Then I imagine you'll be similarly offended by Traversable not having
> Functor and Foldable as superclasses.
Yes, absolutely. It's not just more symbols, it's loss of
intelligibility, since the relations between classes are not revealed.
Code should be lucid.
Traversable looks like my ExtractableFunctor?
class Functor f => ExtractableFunctor f where
fextract :: forall g a . FunctorApplyReturn g => f (g a) -> g (f a)
ftolist :: f a -> [a]
ftolist = ...
-- can be derived from fextract (exercise for the reader)
FunctorApplyReturn is just your Applicative (also Idiom elsewhere).
Ashley Yakeley, Seattle WA
More information about the Libraries