Functor hierarchy proposal and class system extension proposal

Ben Millwood haskell at
Tue Jan 4 20:19:18 CET 2011

On Tue, Jan 4, 2011 at 1:21 PM, Conor McBride
<conor at> wrote:
> Jón's proposal was to improve the latter situation by allowing the subclass
> to specify a default (partial) implementation of a superclass. So we might
> write
>  class Applicative f where
>    return :: x -> f x
>    (<*>) :: f (s -> t) -> f s -> f t
>    instance Functor f where
>      fmap = pure . (<*>)
> giving not only a subclass constraint (Functor f =>) but also a standard
> means to satisfy it. Whenever an Applicative instance is declared, its
> Functor sub-instance is unpacked: buy one, get one free.
> This, on its own, is not quite enough. For one thing, we need a way to
> switch it off. I should certainly be permitted to write something like
>  instance Applicative Blah where
>    return = ...
>    (<*>) = ...
>    hiding instance Functor Blah

The use of 'hiding' here I'd object to, as it really isn't a good
description of what's going on. Personally I'd think it more clear to
explicitly opt into an automatic instance:
instance Applicative Blah where
  return = ...
  (<*>) = ...
  deriving (Functor) -- or something like that

but one of the advantages of John Meachem's original proposal was that
it allowed for example a library author to split up a class without
users changing their instances, which my idea would not do. I suppose
that alone makes it far less useful, but I think there is an argument
to be made about how much of this process we want to be explicit and
how much we want to be implicit.

More information about the Haskell-prime mailing list