<div dir="ltr"><br><div class="gmail_extra">On Wed, Oct 19, 2016 at 3:19 PM, Christopher Allen <span dir="ltr"><<a href="mailto:cma@bitemyapp.com" target="_blank">cma@bitemyapp.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Here catch is:<br>
<br>
catch :: (Exception e, MonadCatch m) => m a -> (e -> m a) -> m a<br><br></blockquote><div><br></div><div>In my mind, this is inferior to the Purescript example, because you have not discharged the MonadCatch instance. That is to say, the result monad continues to have a MonadCatch instance, even though we may want to explicitly express that we have *already* caught any exceptions, so the result type need not be a MonadCatch.</div><div><br></div><div>In the Purescript example, the result monad no longer has the EXCEPTION effect, so you have demonstrated statically that the exception has already been caught! This is very useful. You can't express this in the style you're advocating  (which, to be clear, is the style I use most of the time).</div><div><br></div><div>In other words, the purescript approach has the benefits of both explicitly enumerating the entire monad transformer stack (you can statically determine exactly which effects are possible *and* which are not, and you can discharge individual layers of the stack) and of using typeclass constraints (you aren't typing out redundant information and you don't have to specify where in the monad transformer stack the effect is handled). It's the best of both worlds.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>Another advantage is that the Purescipt example uses a concrete type<br>
<br>
</span>I'm not sure I understand. What are you saying is concrete here?</blockquote><div><br></div><div>I should have been more clear; the type is polymorphic, but does not have any constraints outside of the type. This isn't a formal advantage so much as a psychological/syntactic advantage. As I said, it's inconvenient to have to mentally sub in constraints on the LHS of the "=>" into the type variables on the RHS of the "=>". The Purescript approach is easier to read for me, even though I've been using the typeclass approach for years.</div><div><br></div><div><br></div><div>Like I said, I haven't actually used Purescript, so I'm sure there are additional use cases I'm missing. But this is what stands out.</div><div><br></div><div>Cheers,</div><div>Will</div><div><br></div><div><br></div><div><br></div></div></div></div>