Functor => Pointed => Applicative => Monad

[Antoine Latter]

On Mon, Nov 29, 2010 at 1:08 PM, Tyson Whitehead <twhitehead at gmail.com> wrote:
> 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

Tthere are instances of Functor that are not pointed - as in, most of
Control.Comonad.*. So I don't think that Pointed should be a
constraint on Functor. The real question is if Functor should be a
contraint on Pointed.

Antoine