On Wed, Jan 5, 2011 at 5:03 AM, Isaac Dupree
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.