Functor hierarchy proposal and class system extension proposal

[Ben Millwood]

On Tue, Jan 4, 2011 at 1:21 PM, Conor McBride
<conor at strictlypositive.org> 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.