<div dir="ltr">(Sorry, accidently took off cafe.)<br><br><div class="gmail_quote">On Mon, Oct 19, 2009 at 12:44 AM, Henning Thielemann <span dir="ltr"><<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
On Mon, 19 Oct 2009, Michael Snoyman wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Does the explicit-exception package provide what you need?<br>
<br>
<a href="http://hackage.haskell.org/package/explicit-exception" target="_blank">http://hackage.haskell.org/package/explicit-exception</a><br>
<br>
<br>
I don't think so, but correct me if I'm wrong. I want to make it easy to chain together<br>
computations which could fail in different ways. For example, something like this:<br>
<br>
attemptReadInt :: String -> Attempt Int<br>
attemptLookup :: String -> [(String, String)] -> Attempt String<br>
attemptLookupInt :: String -> [(String, String)] -> Attempt Int<br>
attemptLookupInt k m = attemptLookup k m >>= attemptReadInt<br>
<br>
Now, in the explicit-exception package, I could- in this simple example- define<br>
something like:<br>
<br>
data MyErrors = KeyNotFound | InvalidInt<br>
</blockquote>
<br>
<br></div>
type Attempt = Exceptional MyErrors<div class="im"><br></div></blockquote><div>True; that's what I meant by I could do this in my simple example. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
But this solution would not scale.<br>
</blockquote>
<br></div>
You want to add other exceptions? The idea of my package is to make exceptions explicit in the type. Otherwise you would use extensible-exceptions. Or you could define MyErrors using an existential type.</blockquote><div>
<br>Which is my point. I'm trying to provide a package for non-explicit exceptions. To compare to other programming languages, I think your package is providing the equivalent of Java checked exceptions, while mine is providing (safe) unchecked exceptions. I say safe because you still need to explicitly decide to turn an Attempt into a possible runtime exception which will bring down your program.<br>
<br>Defining MyErrors using an existential type would essentially recreate the entire attempt package; I don't see that purpose in everyone wanted unchecked exceptions needing to reinvent the wheel in non-compatible ways. If multiple libraries use attempt, they can easily have their possible-error-returning functions chain together safely.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Additionally, there's two immediate features I think I would miss from my package:<br>
<br>
1) fail works properly, so an Attempt would be a valid monad response from people who<br>
use that function.<br>
</blockquote>
<br></div>
As far as I understand, 'fail' is used/abused for reporting failed pattern matches in do notation. If a failed pattern match indicates a programming error, it should be a really error, and not something that must be handled at run-time.<br>
</blockquote></div><br>That's a lot of very debateable statements you just made. It might be that it's strongly encouraged to only use fail for failed pattern matching, but in practice you could use it for any monadic failure. Also, there's nothing stopping a user from re-throwing pattern match exceptions received in an Attempt.<br>
<br>Michael<br></div>