Functor => Pointed => Applicative => Monad

[Tyson Whitehead]

On November 29, 2010 11:26:34 Isaac Dupree wrote:
> On 11/29/10 03:39, John Smith wrote:
> > Is there any intention to reorganise the standard class hierarchy,
> > arranging them logically instead of in order of invention? I plagiarised
> > the following example from
> > http://stackoverflow.com/questions/1634911/can-liftm-differ-from-lifta
> > and Trac:
> > 
> > class Functor f where
> > map :: (a -> b) -> f a -> f b
> > 
> > class Functor f => Pointed f where
> > pure :: a -> f a
> 
> Is it useful to have Pointed non-Functors?  (I.e. not superclass).  Er,
> Data.Set is the only example I've come up with (its 'singleton' doesn't
> require Ord on elements but its 'map' does).  Then you'd have things like
> 
> class (Pointed f, Functor f) => Applicative f where

I've wondered about the ordering of Pointed/Functor for awhile.  

Lifting of a type would seem to be something that would require less machinery 
(i.e., impose less structure) than lifting a function to work over lifted 
types.  I would think this should imply the later is more specialized and 
should at minimum not appear further up the class hierarchy (as proposed).

As to whether it should go (Pointed, Functor) => Applicative or Pointed => 
Functor => Applicative, it would seem to me that, just as when given a Monad I 
have Applicative, when given a Functor I have Pointed

pure x = fmap (const x) undefined

Presuming (without proof) that this is the only valid definition given the 
underlying laws, perhaps it should then go Pointed => Functor => Applicative.  

Cheers!  -Tyson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://www.haskell.org/pipermail/libraries/attachments/20101129/1317a14f/attachment.bin