<div class="gmail_quote">On Wed, Jun 30, 2010 at 4:57 PM, Claus Reinke <span dir="ltr"><<a href="mailto:claus.reinke@talk21.com">claus.reinke@talk21.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The current proposal is not trying to fix the fail situation, so this is a bit off topic, but to answer your question:<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
So I prefer 'case xyz of { pat -> mzero/throw/whatever }'. It's more<br>
wordy but clearer. Are there uses out there that really rely on the<br>
conciseness afforded by refutable patterns?<br>
</blockquote>
<br></div>
The stand-alone alternative is more like<br>
<br>
do { p1 <- return x; return e1 } vs <br>
case x of { p1 -> return e1; _ -> mzero}<br>
<br>
which doesn't look much worse until you realize that the<br>
former embeds nicely into existing monadic code, the latter doesn't. So it becomes<br>
<br>
do { ..; p1 <- return x; .. }<br>
<br>
vs<br>
<br>
do { ..; case x of { p1 -> ..; _ -> mzero } }<br>
<br>
and so on for every added pattern. <br>
When I embed Haskell-Coloured Petri Nets in Haskell, the former style can be made to resemble the input language<br>
quite closely (changing from graphical to textual<br>
representation, but with easily recognizable structure).<br></blockquote><div> </div><div>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.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
When writing combinator parsers, type system rules, or<br>
other rule-based embedded languages that embed into<br>
a MonadPlus, it can be similarly helpful to write down only the interesting success cases, without messing up the code with standard failure cases.<font color="#888888"><br></font></blockquote><div><br>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.<br>
<br>-Edward Kmett<br><br><br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><font color="#888888">
Claus</font><div><div></div><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br>