On 17/12/2011, Gregory Crosswhite <gcrosswh...@gmail.com> wrote: > > 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 <co...@strictlypositive.org> wrote: > 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
