Functor => Pointed => Applicative => Monad
twhitehead at gmail.com
Mon Nov 29 20:08:16 CET 2010
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://www.haskell.org/pipermail/libraries/attachments/20101129/1317a14f/attachment.bin
More information about the Libraries