On Wed, Dec 21, 2011 at 8:10 AM, Bas van Dijk <v.dijk....@gmail.com> wrote: > On 16 December 2011 16:26, Yves Parès <limestr...@gmail.com> wrote: >> "1) What about the First type? Do we {-# DEPRECATE #-} it?" >> >> Personnaly, I'm in favor of following the same logic than Int: >> Int itself is not a monoid. You have to be specific: it's either Sum or >> Mult. >> >> It should be the same for Maybe: we remove its instance of Monoid, and we >> only use First and Last. > > The reason you need to be specific with Int is that it's not clear > which semantics (sum or product) you want. The semantics of Maybe are > clear: it's failure-and-prioritized-choice. > > Changing the order of the arguments of mappend should be the job of Dual. > > If we really want to drop the Monoid instance for Maybe and keep First > and Last and also want to be consistent we should also drop the Monoid > instances of [a], a->b, Endo a and of all the tuples.
Interestingly, every one of these examples can been seen as an adaptor from another class. For [a], the monoid is (mzero,mplus). For a -> b and the tuples, the monoid is (pure mempty, liftA2 mappend). For Endo, the monoid is (id, (.)) (from Category) The current monoid instances for [a], a -> a, and the tuples feel like natural choices (in contrast to Maybe), but knowing which operations are used requires some understanding of the design history of the library. That's why I recommend only using mempty and mappend with polymorphic code. -- 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