On Wed, Dec 21, 2011 at 12:20 PM, Conor McBride <co...@strictlypositive.org> wrote: > > On 21 Dec 2011, at 14:07, Erik Hesselink <hessel...@gmail.com> wrote: > >> On Wed, Dec 21, 2011 at 14:10, Bas van Dijk <v.dijk....@gmail.com> wrote: > > >> The semantics of Maybe are >>> >>> >>> clear: it's failure-and-prioritized-choice. >> >> >> Are you sure? > > > Yes. > > >> There are (at least) four Monoid instances for Maybe >> [1]. With a direct instance for Maybe and its Dual you have only >> covered two. > > > Types don't just give data a representation: types evoke structure. The data > stored by Maybe can be made into a monoid in several ways, but the > failure-management role of Maybe makes just one of them appropriate.
This is my view as well. While it's true that the current Monoid instance for Maybe is the only one that isn't captured by an obvious adaptor, I think we'd be better off with a dedicated type for that sort of semigroup-to-monoid transformation. Those obvious adaptors, by the way: newtype MPlus m a = MPlus (m a) instance MonadPlus m => Monoid (MPlus m a) where mempty = MPlus mzero mappend (MPlus x) (MPlus y) = MPlus (mplus x y) newtype LiftA2 m a = LiftA2 (m a) instance (Applicative m, Monoid a) => Monoid (LiftA2 m a) where mempty = LiftA2 (pure mempty) mappend (LiftA2 x) (LiftA2 y) = LiftA2 (liftA2 mappend x y) -- Dave Menendez <d...@zednenem.com> <http://www.eyrie.org/~zednenem/> _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe