Applicative and Functor

[Ashley Yakeley]

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? 
<http://hbase.sourceforge.net/haddock/Org.Org.Semantic.HBase.Category.Ext
ractableFunctor.html>

  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
WWED? http://www.cs.utexas.edu/users/EWD/