<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">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><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><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></div><br></div></div>