PROPOSAL: Add displayException to Exception typeclass

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

PROPOSAL: Add displayException to Exception typeclass

Michael Snoyman
I started a discussion a few weeks back on some theoretical changes to how exceptions are displayed. That discussion covered a lot of different ground. I'd now like to formally propose the original change I mentioned in that thread:

1.  Add a new method to the Exception typeclass:

    -- | Render this exception value in a human-friendly manner. Default implementation: @show@.
    displayException :: e -> String
    displayException = show

2. Modify GHC's default exception handler to use `displayException` instead of `show`.

This change will, on its own, cause no breakage[1] and, without further action, will have no change in program behavior. It does, however, allow users to begin distinguishing between how their exceptions should be `show`n versus how they should be displayed to an end user.

Note that I am *not* proposing at this time any other changes discussed in the previous thread. If someone wants to propose removing Show superclasses, adding a Read superclass, providing a typeRepStack method[2], or something else, please propose it separately.

Discussion period: two weeks.

Michael

[1] Besides introducing a new, possibly clashing identifier name.
[2] That one actually seems like a very good idea to me.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Add displayException to Exception typeclass

Simon Hengel
> 1.  Add a new method to the Exception typeclass:
>
>     -- | Render this exception value in a human-friendly manner. Default
> implementation: @show@.
>     displayException :: e -> String
>     displayException = show

I'm +0.5 on this one, even though I think we should solve this in the
general case.  I think there is a difference between converting
something to a string (display) vs. showing something in a programmer
friendly way (show).  This distinction is not novel, both Python and
Ruby make that distinction (str()/repr() in Python, #to_s/#inspect in
Ruby).

So I would love to have tho following type class:

    class Display a where
      display :: a -> String
      default display :: Show a => a -> String
      display = show

Note that for many Prelude types `show == display`, with the notable
exception of String, where `display = id`.  One use case where this
matters is string interpolation [1][2][3].

Other programming language communities use `toString`, `str` and `to_s`
for this primitive [4].  So maybe ToString/toString would be a better
class/method name.

> 2. Modify GHC's default exception handler to use `displayException`
> instead of `show`.

I'm -1 on this one.  From my perspective most of the time uncaught
exceptions are encountered by programmers.  So I would prefer to have
the programmer friendly version by default.  In cases where I want the
"user friendly behavior" I'm ok with the extra step of adding a custom
exception handler.  Ideally, we would already provide a convenient way
to do so.

Cheers,
Simon

[1] http://hackage.haskell.org/package/interpolate
[2] http://hackage.haskell.org/package/interpolatedstring-qq
[3] http://hackage.haskell.org/package/interpolatedstring-perl6
[4] https://github.com/sol/exceptions-by-language
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Add displayException to Exception typeclass

Roman Cheplyaka-2
On 10/11/14 09:56, Simon Hengel wrote:

>> 1.  Add a new method to the Exception typeclass:
>>
>>     -- | Render this exception value in a human-friendly manner. Default
>> implementation: @show@.
>>     displayException :: e -> String
>>     displayException = show
>
> I'm +0.5 on this one, even though I think we should solve this in the
> general case.  I think there is a difference between converting
> something to a string (display) vs. showing something in a programmer
> friendly way (show).  This distinction is not novel, both Python and
> Ruby make that distinction (str()/repr() in Python, #to_s/#inspect in
> Ruby).
>
> So I would love to have tho following type class:
>
>     class Display a where
>       display :: a -> String
>       default display :: Show a => a -> String
>       display = show
>
> Note that for many Prelude types `show == display`, with the notable
> exception of String, where `display = id`.  One use case where this
> matters is string interpolation [1][2][3].

I would also like a class like that to exist.

But I think it should be based on Text and Text builder rather than
String (and hence be outside of base).

Exceptions are an exception here (haha), because the class is in base,
and so cannot depend on Text. That's why a special method in that class
seems justified to me.

Therefore, I'm in favor of Michael's original proposal here.

>> 2. Modify GHC's default exception handler to use `displayException`
>> instead of `show`.
>
> I'm -1 on this one.  From my perspective most of the time uncaught
> exceptions are encountered by programmers.  So I would prefer to have
> the programmer friendly version by default.  In cases where I want the
> "user friendly behavior" I'm ok with the extra step of adding a custom
> exception handler.  Ideally, we would already provide a convenient way
> to do so.

I guess this is fair.

Roman
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Add displayException to Exception typeclass

Andreas Abel
How about a compromise:

1.  Add a new method to the Exception typeclass:

     -- | Render this exception value in a human-friendly manner.
Default implementation: @show@.
     displayException :: e -> String
     displayException = show

2.  Add a function that can be invoked to change the default handler.

Then one can easily install a generic handler that uses displayException.


On 10.11.2014 16:49, Roman Cheplyaka wrote:

> On 10/11/14 09:56, Simon Hengel wrote:
>>> 1.  Add a new method to the Exception typeclass:
>>>
>>>      -- | Render this exception value in a human-friendly manner. Default
>>> implementation: @show@.
>>>      displayException :: e -> String
>>>      displayException = show
>>
>> I'm +0.5 on this one, even though I think we should solve this in the
>> general case.  I think there is a difference between converting
>> something to a string (display) vs. showing something in a programmer
>> friendly way (show).  This distinction is not novel, both Python and
>> Ruby make that distinction (str()/repr() in Python, #to_s/#inspect in
>> Ruby).
>>
>> So I would love to have tho following type class:
>>
>>      class Display a where
>>        display :: a -> String
>>        default display :: Show a => a -> String
>>        display = show
>>
>> Note that for many Prelude types `show == display`, with the notable
>> exception of String, where `display = id`.  One use case where this
>> matters is string interpolation [1][2][3].
>
> I would also like a class like that to exist.
>
> But I think it should be based on Text and Text builder rather than
> String (and hence be outside of base).
>
> Exceptions are an exception here (haha), because the class is in base,
> and so cannot depend on Text. That's why a special method in that class
> seems justified to me.
>
> Therefore, I'm in favor of Michael's original proposal here.
>
>>> 2. Modify GHC's default exception handler to use `displayException`
>>> instead of `show`.
>>
>> I'm -1 on this one.  From my perspective most of the time uncaught
>> exceptions are encountered by programmers.  So I would prefer to have
>> the programmer friendly version by default.  In cases where I want the
>> "user friendly behavior" I'm ok with the extra step of adding a custom
>> exception handler.  Ideally, we would already provide a convenient way
>> to do so.
>
> I guess this is fair.
>
> Roman
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>


--
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Add displayException to Exception typeclass

Roman Cheplyaka-2
On 10/11/14 11:08, Andreas Abel wrote:

> How about a compromise:
>
> 1.  Add a new method to the Exception typeclass:
>
>     -- | Render this exception value in a human-friendly manner. Default
> implementation: @show@.
>     displayException :: e -> String
>     displayException = show
>
> 2.  Add a function that can be invoked to change the default handler.
>
> Then one can easily install a generic handler that uses displayException.

Agreed.

Roman

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Add displayException to Exception typeclass

Simon Hengel
In reply to this post by Roman Cheplyaka-2
On Mon, Nov 10, 2014 at 10:49:44AM -0500, Roman Cheplyaka wrote:

> On 10/11/14 09:56, Simon Hengel wrote:
> >> 1.  Add a new method to the Exception typeclass:
> >>
> >>     -- | Render this exception value in a human-friendly manner. Default
> >> implementation: @show@.
> >>     displayException :: e -> String
> >>     displayException = show
> >
> > I'm +0.5 on this one, even though I think we should solve this in the
> > general case.  I think there is a difference between converting
> > something to a string (display) vs. showing something in a programmer
> > friendly way (show).  This distinction is not novel, both Python and
> > Ruby make that distinction (str()/repr() in Python, #to_s/#inspect in
> > Ruby).
> >
> > So I would love to have tho following type class:
> >
> >     class Display a where
> >       display :: a -> String
> >       default display :: Show a => a -> String
> >       display = show
> >
> > Note that for many Prelude types `show == display`, with the notable
> > exception of String, where `display = id`.  One use case where this
> > matters is string interpolation [1][2][3].
>
> I would also like a class like that to exist.
>
> But I think it should be based on Text and Text builder rather than
> String (and hence be outside of base).

Yes, this is a valid point.  The Text vs. String issue is one of the
things that made me reluctant to tackle this so far (the other being
that outside of base people may not want to depend on it, orphan
instances, ...).  My given Display class would probably not be that
useful without some `displays :: ShowS`.

I think by now I'm sold on the separate package based on text.

Cheers,
Simon
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Data.Display - Textual representation of Haskell values (was Re: PROPOSAL: Add displayException to Exception typeclass)

Simon Hengel
In reply to this post by Roman Cheplyaka-2
> > So I would love to have tho following type class:
> >
> >     class Display a where
> >       display :: a -> String
> >       default display :: Show a => a -> String
> >       display = show
> >
> > Note that for many Prelude types `show == display`, with the notable
> > exception of String, where `display = id`.  One use case where this
> > matters is string interpolation [1][2][3].
>
> I would also like a class like that to exist.
>
> But I think it should be based on Text and Text builder rather than
> String (and hence be outside of base).

I created an initial draft:

    https://github.com/sol/display/blob/master/src/Data/Display.hs

I named the builder version `displayBuilder` as I could not come up with
any better name (suggestions much appreciated!).

In addition, I think the `display` method has to be outside of the
class.  Otherwise, if somebody defines `display` he end up with the
default implementation of `displayBuilder` (which is based on show and
may not be what is intended).  Any input on that?

Pleas bikeshed hard!

Cheers,
Simon
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Data.Display - Textual representation of Haskell values (was Re: PROPOSAL: Add displayException to Exception typeclass)

Greg Weber
What is the goal of this project? To pretty-print output? Or to be a slightly friendlier version of Show?
To put it another way, what happens with more complicated structures?
As an example, what should the output be for this type [[String]] ?
 
[["abc", "def"], ["ghi"], ["jkl"]]

Or

[  ["abc", "def"]
 , ["ghi"]
 , ["jkl"]
]

On Mon, Nov 10, 2014 at 9:16 AM, Simon Hengel <[hidden email]> wrote:
> > So I would love to have tho following type class:
> >
> >     class Display a where
> >       display :: a -> String
> >       default display :: Show a => a -> String
> >       display = show
> >
> > Note that for many Prelude types `show == display`, with the notable
> > exception of String, where `display = id`.  One use case where this
> > matters is string interpolation [1][2][3].
>
> I would also like a class like that to exist.
>
> But I think it should be based on Text and Text builder rather than
> String (and hence be outside of base).

I created an initial draft:

    https://github.com/sol/display/blob/master/src/Data/Display.hs

I named the builder version `displayBuilder` as I could not come up with
any better name (suggestions much appreciated!).

In addition, I think the `display` method has to be outside of the
class.  Otherwise, if somebody defines `display` he end up with the
default implementation of `displayBuilder` (which is based on show and
may not be what is intended).  Any input on that?

Pleas bikeshed hard!

Cheers,
Simon
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [core libraries] Data.Display - Textual representation of Haskell values (was Re: PROPOSAL: Add displayException to Exception typeclass)

Michael Snoyman
In reply to this post by Simon Hengel


On Mon Nov 10 2014 at 7:17:07 PM Simon Hengel <[hidden email]> wrote:
> > So I would love to have tho following type class:
> >
> >     class Display a where
> >       display :: a -> String
> >       default display :: Show a => a -> String
> >       display = show
> >
> > Note that for many Prelude types `show == display`, with the notable
> > exception of String, where `display = id`.  One use case where this
> > matters is string interpolation [1][2][3].
>
> I would also like a class like that to exist.
>
> But I think it should be based on Text and Text builder rather than
> String (and hence be outside of base).

I created an initial draft:

    https://github.com/sol/display/blob/master/src/Data/Display.hs


Is this intended to be a standalone library, or part of text (or some other package?).
 
I named the builder version `displayBuilder` as I could not come up with
any better name (suggestions much appreciated!).

In addition, I think the `display` method has to be outside of the
class.  Otherwise, if somebody defines `display` he end up with the
default implementation of `displayBuilder` (which is based on show and
may not be what is intended).  Any input on that?


I don't think this is a good enough reason to avoid a possible optimization. I'd recommend documenting this aspect of the typeclass thoroughly, and then let people shoot themselves in the foot if desired.

Michael

PS: I just saw Greg's email, I'd like to +1 his questions, clarification is good.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [core libraries] Data.Display - Textual representation of Haskell values (was Re: PROPOSAL: Add displayException to Exception typeclass)

Michael Snoyman


On Mon Nov 10 2014 at 8:28:18 PM Michael Snoyman <[hidden email]> wrote:
On Mon Nov 10 2014 at 7:17:07 PM Simon Hengel <[hidden email]> wrote:
> > So I would love to have tho following type class:
> >
> >     class Display a where
> >       display :: a -> String
> >       default display :: Show a => a -> String
> >       display = show
> >
> > Note that for many Prelude types `show == display`, with the notable
> > exception of String, where `display = id`.  One use case where this
> > matters is string interpolation [1][2][3].
>
> I would also like a class like that to exist.
>
> But I think it should be based on Text and Text builder rather than
> String (and hence be outside of base).

I created an initial draft:

    https://github.com/sol/display/blob/master/src/Data/Display.hs


Is this intended to be a standalone library, or part of text (or some other package?).
 
I named the builder version `displayBuilder` as I could not come up with
any better name (suggestions much appreciated!).

In addition, I think the `display` method has to be outside of the
class.  Otherwise, if somebody defines `display` he end up with the
default implementation of `displayBuilder` (which is based on show and
may not be what is intended).  Any input on that?


I don't think this is a good enough reason to avoid a possible optimization. I'd recommend documenting this aspect of the typeclass thoroughly, and then let people shoot themselves in the foot if desired.

Michael

PS: I just saw Greg's email, I'd like to +1 his questions, clarification is good.

One other question/comment: I'm not convinced that the `String` instance is a good thing. It will conflict with any other list instance, unless you turn on OverlappingInstances (which I hope you don't). You could use the `showList` hack, but we should really clarify first what the intended list instance is.

Michael 

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Data.Display - Textual representation of Haskell values (was Re: PROPOSAL: Add displayException to Exception typeclass)

Evan Laforge
In reply to this post by Greg Weber
On Mon, Nov 10, 2014 at 10:25 AM, Greg Weber <[hidden email]> wrote:
> What is the goal of this project? To pretty-print output? Or to be a
> slightly friendlier version of Show?
> To put it another way, what happens with more complicated structures?
> As an example, what should the output be for this type [[String]] ?

I've long used a Pretty class, which outputs a Doc from a pretty
printing library.  That way it can be flattened into one line or
wrapped, depending on context.  Most of the readability comes from the
layout, and the rest comes from how I can omit "less important" data
or use non-haskell syntax (e.g. {k: v} for maps).  So for me a Display
class that doesn't include layout wouldn't be very useful.

I include all data in Show (and usually derive it), which means that
it's valid syntax and I automatically parse and then format it with
Language.Haskell.Pretty.

I don't know if this is applicable to a general purpose Display class,
because then it would have to pick a pretty printing library, which
means it's making choices about layout and formatting, which means
it's not really universal.  E.g. I currently use HughesPJ but modified
to avoid piling up on the right margin, but having been meaning for a
long time to switch to an indentation based formatter that uses Text.

Also, I use the showList hack.  It works.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [core libraries] Data.Display - Textual representation of Haskell values (was Re: PROPOSAL: Add displayException to Exception typeclass)

Roman Cheplyaka-2
In reply to this post by Michael Snoyman
On 10/11/14 13:32, Michael Snoyman wrote:
> One other question/comment: I'm not convinced that the `String` instance is
> a good thing. It will conflict with any other list instance, unless you
> turn on OverlappingInstances (which I hope you don't).

I do. Why don't you?

Roman

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Data.Display - Textual representation of Haskell values (was Re: PROPOSAL: Add displayException to Exception typeclass)

Greg Weber
In reply to this post by Evan Laforge


On Mon, Nov 10, 2014 at 10:51 AM, Evan Laforge <[hidden email]> wrote:
On Mon, Nov 10, 2014 at 10:25 AM, Greg Weber <[hidden email]> wrote:
> What is the goal of this project? To pretty-print output? Or to be a
> slightly friendlier version of Show?
> To put it another way, what happens with more complicated structures?
> As an example, what should the output be for this type [[String]] ?

I've long used a Pretty class, which outputs a Doc from a pretty
printing library.  That way it can be flattened into one line or
wrapped, depending on context.  Most of the readability comes from the
layout, and the rest comes from how I can omit "less important" data
or use non-haskell syntax (e.g. {k: v} for maps).  So for me a Display
class that doesn't include layout wouldn't be very useful.


This is what I was hinting at.
 
I include all data in Show (and usually derive it), which means that
it's valid syntax and I automatically parse and then format it with
Language.Haskell.Pretty.

I don't know if this is applicable to a general purpose Display class,
because then it would have to pick a pretty printing library, which
means it's making choices about layout and formatting, which means
it's not really universal.  E.g. I currently use HughesPJ but modified
to avoid piling up on the right margin, but having been meaning for a
long time to switch to an indentation based formatter that uses Text.

I am wondering if it is possible to have a standard code display data type for marking up code with display information that
can then be converted to work with different pretty-printing libraries.

Perhaps this current project would follow under your second principle though of omitting less important data and using non-Haskell syntax
and it could be used by another project that deals with the layout issue.
Still, as it stands, I don't think that will work. A display type for a Map really needs to specify how a key/value pairing is displayed, and how the Map container is displayed, and needs to hand off those instructions to a layout engine.

The existing Show actually fares better because it is parse-able Haskell code.
That way libraries such as groom exist which know how to parse it and can change the layout.


Also, I use the showList hack.  It works.


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [core libraries] Data.Display - Textual representation of Haskell values (was Re: PROPOSAL: Add displayException to Exception typeclass)

Michael Snoyman
In reply to this post by Roman Cheplyaka-2


On Mon Nov 10 2014 at 9:55:28 PM Roman Cheplyaka <[hidden email]> wrote:
On 10/11/14 13:32, Michael Snoyman wrote:
> One other question/comment: I'm not convinced that the `String` instance is
> a good thing. It will conflict with any other list instance, unless you
> turn on OverlappingInstances (which I hope you don't).

I do. Why don't you?



Just the general aversion to OverlappingInstances. The few times in the past I've attempted to use OverlappingInstances to solve a problem, it turned out poorly, which has left a bad taste in my mouth.

In this case, I wouldn't want some orphan instance of `instance Display [Int]`, for example, changing behavior of my program. That's not a very strong reason to be sure; my primary concern is the unforeseen complications it will result in.

Michael


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Data.Display - Textual representation of Haskell values (was Re: PROPOSAL: Add displayException to Exception typeclass)

Evan Laforge
In reply to this post by Greg Weber
On Mon, Nov 10, 2014 at 12:13 PM, Greg Weber <[hidden email]> wrote:
> Still, as it stands, I don't think that will work. A display type for a Map
> really needs to specify how a key/value pairing is displayed, and how the
> Map container is displayed, and needs to hand off those instructions to a
> layout engine.

Relatedly, I think what "pretty" means is project specific.  For
example, my pretty floats print like "%.2f", because I usually don't
need to see anything past the 3rd decimal point.   When you're
scanning a list of numbers looking for oddities, having everything
formatted this way makes a huge difference for readability.  But
someone else will complain that everything is .99, and will find
scientific notation more useful.

But a library of utilities designed to construct your own Pretty /
Display class would be fine.  Of course that's basically what the
various pretty-print libraries already are.

Mostly I just ask that library authors provide the functions to take
apart error types so I can write my own Pretty instances.


Of course python's str() / repr() doesn't worry about formatting
either.  Maybe it's useful to have a Show-alike somewhere in between
Show and Pretty.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [core libraries] Data.Display - Textual representation of Haskell values (was Re: PROPOSAL: Add displayException to Exception typeclass)

Erik Hesselink
In reply to this post by Michael Snoyman
On Mon, Nov 10, 2014 at 9:16 PM, Michael Snoyman <[hidden email]> wrote:

>
> On Mon Nov 10 2014 at 9:55:28 PM Roman Cheplyaka <[hidden email]> wrote:
>>
>> On 10/11/14 13:32, Michael Snoyman wrote:
>> > One other question/comment: I'm not convinced that the `String` instance
>> > is
>> > a good thing. It will conflict with any other list instance, unless you
>> > turn on OverlappingInstances (which I hope you don't).
>>
>> I do. Why don't you?
>>
> Just the general aversion to OverlappingInstances. The few times in the past
> I've attempted to use OverlappingInstances to solve a problem, it turned out
> poorly, which has left a bad taste in my mouth.
>
> In this case, I wouldn't want some orphan instance of `instance Display
> [Int]`, for example, changing behavior of my program. That's not a very
> strong reason to be sure; my primary concern is the unforeseen complications
> it will result in.

That's still possible if the instance for [Int] has
OverlappingInstances turned on, even if you personally don't. It has
to be enabled on *either* instance, not on both.

Erik
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Add displayException to Exception typeclass

Herbert Valerio Riedel
In reply to this post by Andreas Abel
On 2014-11-10 at 17:08:56 +0100, Andreas Abel wrote:

[...]

> 2.  Add a function that can be invoked to change the default handler.

like

http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-Conc-Sync.html#v:setUncaughtExceptionHandler

?
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Add displayException to Exception typeclass

John Lato-2
+1 to adding the new displayException method.

-1 to changing the default handler, `setUncaughtExceptionHandler` seems like a better solution IMHO.

On Tue Nov 11 2014 at 5:52:25 AM Herbert Valerio Riedel <[hidden email]> wrote:
On 2014-11-10 at 17:08:56 +0100, Andreas Abel wrote:

[...]

> 2.  Add a function that can be invoked to change the default handler.

like

http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-Conc-Sync.html#v:setUncaughtExceptionHandler

?
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Add displayException to Exception typeclass

Simon Hengel
In reply to this post by Herbert Valerio Riedel
> > 2.  Add a function that can be invoked to change the default handler.
>
> like
>
> http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-Conc-Sync.html#v:setUncaughtExceptionHandler

I think getting the exception handler right is non-trivial, e.g.

 - stdout has to be flushed, ignoring any exceptions while doing so
 - output has to go to stderr, not stdout
 - program has to terminate with the correct exit code (at least if it's
   the main thread)
 - I would also assume that ExitCode exceptions need special handling,
   even though I don't see any code for that in the default handler [1],
   so maybe this is already taken care of before the handler is invoked

So I think it makes sense to provide a primitive along the lines of

    useDisplayExceptionHandler :: IO ()

which does "the right thing" (I'm not very opinionated about the name).

One more thing I noticed is that the exception handler set with
setUncaughtExceptionHandler is used for both the main thread and other
threads.  I'm undecided whether this would be desirable or not for
useDisplayExceptionHandler.  Thoughts?

Cheers,
Simon

[1] http://hackage.haskell.org/package/base-4.7.0.1/docs/src/GHC-Conc-Sync.html#uncaughtExceptionHandler
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [core libraries] Data.Display - Textual representation of Haskell values (was Re: PROPOSAL: Add displayException to Exception typeclass)

Simon Hengel
In reply to this post by Michael Snoyman
> > I created an initial draft:
> >
> >     https://github.com/sol/display/blob/master/src/Data/Display.hs
> >
> >
> Is this intended to be a standalone library, or part of text (or some other
> package?).

I would assume a separate package, but if we manage to foster consensus
and if there is a strong vote for it, then I would be more than happy to
get it merged into text.

> > I named the builder version `displayBuilder` as I could not come up with
> > any better name (suggestions much appreciated!).
> >
> > In addition, I think the `display` method has to be outside of the
> > class.  Otherwise, if somebody defines `display` he end up with the
> > default implementation of `displayBuilder` (which is based on show and
> > may not be what is intended).  Any input on that?
> >
> >
> I don't think this is a good enough reason to avoid a possible
> optimization. I'd recommend documenting this aspect of the typeclass
> thoroughly, and then let people shoot themselves in the foot if desired.

Is this about avoiding the intermediate Builder?  If so, I think we can
achieve this with rewrite rules, e.g.:

    {-# RULES "display/Text" display = id #-}
    {-# RULES "display/String" display = fromString #-}

I'm still puzzled whether there are other use cases where it would be
beneficial to have `display` in the class.

BTW, one nice thing that I think we can do if we do not have `display`
in the class is providing versions for strict and lazy text [1].
Technically I think this is also possible if `display` is part of the
class definition, but then you run into name clashes if you want to
export the full class from both Data.Display and Data.Display.Lazy.

> PS: I just saw Greg's email, I'd like to +1 his questions,
> clarification is good.

Ok, I'll add my perspective on that branch of the discussion ;).

Cheers,
Simon

[1] https://github.com/sol/display/pull/1/files
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
12