On Wed, Jun 30, 2010 at 4:57 PM, Claus Reinke
<claus.reinke@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