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
