<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 26, 2015 at 1: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></blockquote><div><br></div><div>That is not what I was trying to get at in my feedback. Using pattern synonyms to maintain backwards compatibility with the current form is independent of what many variations of the new form look like.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></blockquote></div><br></div></div>