Proposal: Add exception info

[Greg Weber]

On Sun, Apr 26, 2015 at 1:26 PM, Michael Sloan <mgsloan at gmail.com> wrote:

> 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.
>

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.


> On Thu, Apr 23, 2015 at 6:30 AM, Greg Weber <greg at gregweber.info> wrote:
>
>>
>>
>> On Tue, Apr 21, 2015 at 1:55 PM, Michael Sloan <mgsloan at gmail.com> wrote:
>>
>>>
>>> On Tue, Apr 21, 2015 at 8:23 AM, Greg Weber <greg at gregweber.info> wrote:
>>>
>>>>
>>>> On Tue, Apr 14, 2015 at 11:38 AM, Michael Sloan <mgsloan at gmail.com>
>>>> wrote:
>>>>
>>>>>     data SomeException = forall e . Exception e =>
>>>>>         SomeExceptionWithInfo e [SomeExceptionInfo]
>>>>>
>>>>>     data SomeExceptionInfo = forall a . ExceptionInfo a =>
>>>>>         SomeExceptionInfo a
>>>>
>>>>
>>>> Is it necessary for SomeExceptionWithInfo to have a list of a forall
>>>> data type?
>>>> Are Exceptions really that mysterious, or can we more concretely
>>>> describe the information that should be attached to an exception?
>>>>
>>>>     SomeExceptionWithInfo e IsAsync CallStack ImplicitStack
>>>>
>>>
>>> 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.
>>>
>>
>> The usual approach is to use information hiding. We are being rescued by
>> pattern synonyms right now because the constructor is directly exported.
>> Why not hide what needs to be hidden to make this more extensible and use
>> smart constructors, etc?.
>>
>>
>>>
>>>
>>>> I am still open to the idea of adding a forall data scratchpad, but can
>>>> we at least try to specify some standard fields?
>>>>
>>>>     SomeExceptionWithInfo e IsAsync CallStack ImplicitStack
>>>> [SomeExceptionInfo]
>>>>
>>>
>>> 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.
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150427/549a38c9/attachment.html>