#4159: move Monad and MonadFix instances for Either from mtl to base

Edward Kmett ekmett at gmail.com
Wed Jun 30 17:13:59 EDT 2010


On Wed, Jun 30, 2010 at 4:57 PM, Claus Reinke <claus.reinke at talk21.com>wrote:

> The current proposal is not trying to fix the fail situation, so this is a
> bit off topic, but to answer your question:
>
>
>  So I prefer 'case xyz of { pat -> mzero/throw/whatever }'.  It's more
>> wordy but clearer.  Are there uses out there that really rely on the
>> conciseness afforded by refutable patterns?
>>
>
> The stand-alone alternative is more like
>
>   do { p1 <- return x; return e1 }    vs
>   case x of { p1 -> return e1; _ -> mzero}
>
> which doesn't look much worse until you realize that the
> former embeds nicely into existing monadic code, the latter doesn't. So it
> becomes
>
>   do { ..; p1 <- return x; .. }
>
> vs
>
>   do { ..; case x of { p1 -> ..; _ -> mzero } }
>
> and so on for every added pattern.
> When I embed Haskell-Coloured Petri Nets in Haskell, the former style can
> be made to resemble the input language
> quite closely (changing from graphical to textual
> representation, but with easily recognizable structure).
>

And you can have these semantics, just tied to another monad with nice names
for the different form, which is clearer about being a monad for handling
errors.


> When writing combinator parsers, type system rules, or
> other rule-based embedded languages that embed into
> a MonadPlus, it can be similarly helpful to write down only the interesting
> success cases, without messing up the code with standard failure cases.
>

I'm not making the case for killing fail in general here. I merely agree
with Ross that the right call is to remove the spurious constraint on
Either. I wholeheartedly support the creation of another monad with suitable
semantics for your purposes.

-Edward Kmett



Claus
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20100630/a9f4d90e/attachment.html


More information about the Libraries mailing list