Re: [Haskell-cafe] Alternative versus Monoid
On 16 December 2011 16:26, Yves Parès <limestrael@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. And instead define Monoid instance for First [a], Last [a], First (a->b), Last (a->b), etc. I don't think this is what we want. Regards, Bas
On Wed, Dec 21, 2011 at 14:10, Bas van Dijk <v.dijk.bas@gmail.com> wrote:
On 16 December 2011 16:26, Yves Parès <limestrael@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.
Are you sure? There are (at least) four Monoid instances for Maybe [1]. With a direct instance for Maybe and its Dual you have only covered two. Erik [1] https://byorgey.wordpress.com/2011/04/18/monoids-for-maybe/
On 21 Dec 2011, at 14:07, Erik Hesselink <hesselink@gmail.com> wrote:
On Wed, Dec 21, 2011 at 14:10, Bas van Dijk <v.dijk.bas@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. Cheers Conor
Erik
[1] https://byorgey.wordpress.com/2011/04/18/monoids-for-maybe/
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On Wed, Dec 21, 2011 at 12:20 PM, Conor McBride <conor@strictlypositive.org> wrote:
On 21 Dec 2011, at 14:07, Erik Hesselink <hesselink@gmail.com> wrote:
On Wed, Dec 21, 2011 at 14:10, Bas van Dijk <v.dijk.bas@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 <dave@zednenem.com> <http://www.eyrie.org/~zednenem/>
On Wed, Dec 21, 2011 at 8:10 AM, Bas van Dijk <v.dijk.bas@gmail.com> wrote:
On 16 December 2011 16:26, Yves Parès <limestrael@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 <dave@zednenem.com> <http://www.eyrie.org/~zednenem/>
participants (4)
-
Bas van Dijk -
Conor McBride -
David Menendez -
Erik Hesselink