On Mon, Nov 29, 2010 at 1:08 PM, 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
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