[Haskell-cafe] Alternative versus Monoid

David Menendez dave at zednenem.com
Wed Dec 21 19:08:20 CET 2011


On Wed, Dec 21, 2011 at 12:20 PM, Conor McBride
<conor at strictlypositive.org> wrote:
>
> On 21 Dec 2011, at 14:07, Erik Hesselink <hesselink at gmail.com> wrote:
>
>> On Wed, Dec 21, 2011 at 14:10, Bas van Dijk <v.dijk.bas at 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 at zednenem.com>
<http://www.eyrie.org/~zednenem/>



More information about the Haskell-Cafe mailing list