<div dir="ltr">I have to confess that I don't really like this proposal in its current form.<div><br></div><div>We use a little bit of Typeable magic in SomeException to model an open sum type. It is more or less "just enough" to get us an open set of exceptions on which we can match.</div><div><br></div><div>That gives us a nice case analysis construction, we can basically reason type by type and ask if SomeException _is_ a particular data type without losing any information.</div><div><br></div><div>Theoretically it means I can give you a nice prism or case handler for it, match on it, rethrow it and nothing is lost.</div><div><br></div><div>This proposal gives up a very nice property in exchange for an ad hoc ability to decorate exceptions with anything we want. This strikes me as a short term gain in exchange for giving up a lot of future reasoning power. What is your exception decorated with? Go spend O(n) time rummaging through the list of attached decorations to find out! =/</div><div><br></div><div>I'm not offering a concrete worked solution, but there are many other points in this design space. e.g. having a class to let you attach the particular information you want to particular exceptions, having an exception type you can throw with a stack intact that acts as an exception transformer, etc.</div><div><br></div><div>None of those require us to give up the simplicity of the open exceptions, but those first two obvious directions have obvious drawbacks, hence why "I'm not offering a concrete worked solution."</div><div><br></div><div>Davean's variant narrows the focus down considerably. Limiting it to just the issue at hand, rather than trying to construct a solution to all sorts of problems we haven't even thought of yet. I could get behind something with a more retrenched scope, like that.</div><div><br></div><div><div>That said, I'd very much rather err on the side of doing nothing rather than do the wrong thing here.</div><div><br></div><div>We'll be stuck with it for a long time.</div></div><div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 26, 2015 at 4:26 PM, Michael Sloan <span dir="ltr"><<a href="mailto:mgsloan@gmail.com" target="_blank">mgsloan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Right, we have a choice between making a breaking change towards a more standard API, or using a rather new language extension (bidirectional pattern synonyms) to avoid breakage.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 23, 2015 at 6:30 AM, Greg Weber <span dir="ltr"><<a href="mailto:greg@gregweber.info" target="_blank">greg@gregweber.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Apr 21, 2015 at 1:55 PM, Michael Sloan <span dir="ltr"><<a href="mailto:mgsloan@gmail.com" target="_blank">mgsloan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Apr 21, 2015 at 8:23 AM, Greg Weber <span dir="ltr"><<a href="mailto:greg@gregweber.info" target="_blank">greg@gregweber.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span><br><div class="gmail_quote">On Tue, Apr 14, 2015 at 11:38 AM, Michael Sloan <span dir="ltr"><<a href="mailto:mgsloan@gmail.com" target="_blank">mgsloan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><font face="arial, helvetica, sans-serif"> data SomeException = forall e . Exception e =><br> SomeExceptionWithInfo e [SomeExceptionInfo]<br><br> data SomeExceptionInfo = forall a . ExceptionInfo a =><br> SomeExceptionInfo a</font></blockquote></div><br></span>Is it necessary for SomeExceptionWithInfo to have a list of a forall data type?</div><div class="gmail_extra">Are Exceptions really that mysterious, or can we more concretely describe the information that should be attached to an exception?</div><div class="gmail_extra"><br></div><div class="gmail_extra"> SomeExceptionWithInfo e IsAsync CallStack ImplicitStack</div></div></blockquote><div><br></div></span><div>I did consider this option, but I think as soon as a fixed set is selected, someone's going to put something else in it. Usually we wouldn't want to use such a 'dynamic' mechanism in Haskell, but it's appropriate for something so global as the type used to throw exceptions.</div></div></div></div></blockquote><div><br></div></span><div>The usual approach is to use information hiding. We are being rescued by pattern synonyms right now because the constructor is directly exported.</div><div>Why not hide what needs to be hidden to make this more extensible and use smart constructors, etc?.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">I am still open to the idea of adding a forall data scratchpad, but can we at least try to specify some standard fields?</div><div class="gmail_extra"><br></div><div class="gmail_extra"> SomeExceptionWithInfo e IsAsync CallStack ImplicitStack [SomeExceptionInfo]</div></div></blockquote><div><br></div></span><div>This is an interesting idea. I particularly see value in having 'IsAsync' be a part of the Exception. This is because `throwIO` / `throw` would need to set this to False when rethrowing async exceptions.</div></div></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>