<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 26, 2015 at 2:37 PM, Edward Kmett <span dir="ltr"><<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@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"><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></blockquote><div> </div><div>Yep, I agree that giving up this property sucks. It's discussed at the end of the proposal.</div><div><br></div><div>Rummaging through the list of decorations also sucks. My reasoning for that being acceptable is that if these annotations are used primarily for diagnostic purposes, then performance isn't so crucial.</div><div><br></div><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"><div dir="ltr"><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></blockquote><div><br></div><div>To me, whether we use closed or open datatypes is tertiary to the main issue of how info gets associated with exceptions. If the main issue with my proposal is the breakage of the information preservation of `fromException`, as far as I can tell, that is not addressed by Davean's proposal. So, the narrowing of scope bought us nothing but having simpler types to talk about.</div><div><br></div><div>One thing to note is that `fromException` does not guarantee preservation of information. So, this only breaks an informal property, not one that is documented. Admittedly, it's one that people are used to relying on.</div><div> </div><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"><div dir="ltr"><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></blockquote><div><br></div><div>Yes, such core changes should be made with great care. I hesitated to post the proposal due to this, but was hoping that a more palatable, backwards compatible solution would come up in discussion.</div><div><br class="">While I don't want to get stuck with a bad API, I also don't want to be stuck with uninformative exceptions. The new parts of the API can be stuck in an "Internal" module, and marked specifically for debugging purposes only. This way, base reserves the right to revert this particular API choice if a better option comes along.<br></div><div><br></div><div>Personally, I want callstacks for every exception thrown, and that's what this proposal provides.</div><div> </div><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"><div dir="ltr"><span class=""><font color="#888888"><div>-Edward</div></font></span></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">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></div></div><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"><div><div class="h5"><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><div><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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><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"><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></div></div><span class="">_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">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></span></blockquote></div><br></div>
</blockquote></div><br></div></div>