Functor hierarchy proposal and class system extension proposal

[Ben Millwood]

On Wed, Jan 5, 2011 at 5:03 AM, Isaac Dupree
<ml at isaac.cedarswampstudios.org> wrote:
> On 01/04/11 19:48, Ben Millwood wrote:
>>
>> There's a fair question in whether we want deviation from the default
>> at all (although I think the answer is probably yes). I think it's
>> reasonable that any type that is an instance of Monad be forced to
>> have ap = (<*>), for example, so really the only reason I can see we'd
>> want to be able to override those functions would be for efficiency.
>
> Remember the example
> Monad implies Functor (fmap = Control.Monad.liftM)
> Traversable implies Functor (fmap = Data.Traversable.fmapDefault)
>
> e.g. [] and Maybe are instances of all these classes.
>
> yes, liftM and fmapDefault probably must *do* the same thing[*], but one of
> those definitions still needs to be picked.

This is interesting, yes, and I suppose that's what the 'hiding' was
for, but it seems uglier to me to have a hiding clause on every
instance declaration except one. I suppose if there was an explicit
Functor instance this wouldn't be a problem, as neither implicit
instance would be used in that case. Or if there wasn't an explicit
Functor instance, but there was a definition for fmap in one of the
instances, then that would be used - if there was more than one
definition for fmap of course that would be an error. It would seem
irritating if I had Traversable defined for some type, and I defined
Applicative, and this caused the Functor instance to break, but this
is not necessarily a critical problem.

> [*probably--I'm haven't convinced myself that it's true in all cases of
> "deepening"-type class hierarchies though--we are here trying to engineer to
> support all cases of "deepening" hierarchies.]

I think it would be unpleasantly surprising if ap and (<*>) behaved
differently. If there was another desirable behaviour for <*> I'd
think a newtype would be appropriate.