On 17/12/2011, Gregory Crosswhite
On Dec 17, 2011, at 12:51 PM, Matthew Farkas-Dyck wrote:
By my reason, the instance (Monoid a => Monoid (Maybe a)) is appropriate, since we have another class for inner-type-agnostic choice -- Alternative! (and MonadPlus, but that's essentially the same, and would be if (Functor m => Applicative m => Monad m), as it ought).
Yes, but the problem here is that having different behavior for Alternative, MonadPlus, and Monoid instances is inherently confusing, in the sense that this would almost certainly surprise someone who wasn't already aware of the difference between the instances.
On 17/12/2011, Conor McBride
So your argument is to create incoherence because we can. I'm not convinced.
No, my argument is that Monoid and Alternative ought to have nonsame semantics, since one is a class of types of kind (*), and the other, (* -> *). Thus, Monoid operations ought to mean the whole type, and Alternative operations, just the outer type. It shouldn't be a surprise -- it's impossible to put a constraint on the inner type for an Alternative instance, since there is none (^_~)
(Functor m => Applicative m => Monad m), as it ought. and as it already is in Strathclyde...
By default superclass instances, you mean? If so (and I understand correctly), that's not quite the same; If I write, for (Applicative FooBar -> FooBar) instance Monad FooBar where x >>= f = ... then return would be undefined, despite pure (which ought to be in its own class, anyhow (ō_ō)). Cheers, Matthew Farkas-Dyck