Re: [Haskell-cafe] Alternative versus Monoid

On Wed, Dec 21, 2011 at 8:10 AM, Bas van Dijk wrote:

On 16 December 2011 16:26, Yves Parès 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 http://www.eyrie.org/~zednenem/