Functor => Applicative => Monad

[Conor McBride]

On 6 Dec 2010, at 15:47, Stephen Tetley wrote:

> Me thinks there's more value that "the next language after Haskell"
> might have such a hierarchy than Haskell itself.

I should advise anyone designing the next language after Haskell
to think about these issues and a great deal more, when it comes
to organising functorial structure and programming with computational
effects.

> At Haskell 1.3 I think there was one text book (Davie), possibly none
> at Haskell 1.4 and many at Haskell 98. The value of invalidating 12 or
> so years of documentation for "logic" seems somewhat questionable from
> my perspective. If either proposal were limited to just adding class
> constraints to get the desired hierarchy rather than eliminating
> methods, they might have more legs...

Right. This issue is often mentioned as a motivating example for various
language proposals to allow superclass method definitions in instance
declarations and indeed default superclass instances in subclass
declarations. I don't know the status of these proposals, and what else
they're trying to achieve besides the telescoping of multiple instance
declarations.

I'd like to be able to say something like

   class Functor f where
     fmap :: (s -> t) -> f s -> f t

   class Functor f => Applicative f where
     return :: x -> f x
     (<*>) :: f (s -> t) -> f s -> f t
     instance Functor f where
       fmap = (<*>) . return

   class Applicative f => Monad f where
     (>>=) :: f s -> (s -> f t) -> f t
     instance Applicative f where
       ff <*> fs = ff >>= \ f -> fs >>= \ s -> return (f s)

(possibly without the duplicated constraint) then declare Monad  
instances
as before, and collect all three. The obvious dumb way to unpack these
compound declarations would be to generate a superclass instance from
each subclass instance according to the scheme supplied in the class
(overriding defaults as demanded).

I'm sure that's hopelessly naive for reasons I'm just too, er,  
hopelessly
naive to see right now. It does, however, have the merit of requiring  
only
the awareness of which methods belong to which class and a spot of
textual rearrangement, to be delivered on top of Haskell as it stands.

Does anybody have a Haskell preprocessor they could just hack this into
for a laugh over Chrimbo?

Cheers

Conor