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

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

+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 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 Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

+1 for providing an easy way to install an exception handler that uses the display function. You could consider to just provide displayExceptionHandler :: SomeException -> IO () with a hint in the documentation to install it via setUncaughtExceptionHandler displayExceptionHandler That might be slightly more modular, as one could add some pre or post-processing to displayExceptionHandler. Cheers, Andreas On 11.11.2014 03:38, Simon Hengel 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:se...

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

-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/

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

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 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 Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Mon, Nov 10, 2014 at 10:51 AM, Evan Laforge wrote:

On Mon, Nov 10, 2014 at 10:25 AM, Greg Weber 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.

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.

I think it's at least technically possible to provide addition formatting behavior through newtypes (e.g. polymorphic, on RealFloat).

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.

That is basically where I was heading at. Cheers, Simon

On Mon, Nov 10, 2014 at 11:31 PM, Simon Hengel wrote:

On Mon, Nov 10, 2014 at 10:25:45AM -0800, Greg Weber wrote:

...

What is the goal of this project? To pretty-print output? Or to be a slightly friendlier version of Show?

From my perspective display would be akin to str()/#to_s in Python/Ruby. So I was not thinking to tackle pretty-printing in general.

My *very personal* main use case, that I don't see other good solutions for, is string interpolation. Currently I have a crude hack in interpolate [1] that does the right thing for String, Text and many prelude types (see also [2] if you are curious).

But even more important to me is that we come up with something that is general, has minimal dependencies and is not controversial, so that people are willing to depend on it and provide instances.

Your interpolate package looks the same as shakespeare-text, and Display seems similar to ToText. http://hackage.haskell.org/package/shakespeare-2.0.1.1/docs/Text-Shakespeare... It would make sense to have a single Display typeclass.

[1] https://github.com/sol/interpolate/blob/9be1f6d15722c58e467e7ebc0cb6dc6fb2c4... [2] http://sol.github.io/interpolate-talk/

On Mon Nov 10 2014 at 7:17:07 PM Simon Hengel 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.

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

On Mon, Nov 10, 2014 at 9:16 PM, Michael Snoyman wrote:

On Mon Nov 10 2014 at 9:55:28 PM Roman Cheplyaka 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

...

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

...

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

Any case where there are functions already defined in terms of Text that `displayBuilder` is simply wrapping.

Just to properly understand that point, in that cases I could still try to remedy this with rewrite rules (with the limitations you mentioned above), right? Or is there an other aspect to it?

...

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.

Why not have `display` and `displayLazy`, or something like that?

That would leave us with three methods, say: class Display a where displayBuilder :: a -> Builder default displayBuilder :: Show a => a -> Builder displayBuilder = fromString . show displayLazy :: a -> LT.Text displayLazy = toLazyText . displayBuilder display :: a -> Text display = toStrict . displayLazy Which comes with the big warning attached that if you define any of display/displayLazy, you also have to define displayBuilder. I guess alternatively we could also put the default signature on `display`, where `display` would then always be required. So as I understand it, the dowside is that a user can break the invariants between display/displayLazy/displayBuilder by accident. The up side is that it may be more efficient. I have no picture on how big the potential performance gain would be. If it is non-noticable for most practical cases, I would lean towards the simpler solution. An other direction could be to challenge whether we actually need the Builder version at all. I see that this is useful if we plan to apply `displayBuilder` recursively. If that use case is not prevalent, using Builder may also be less crucial (which again posses the question to me whether we really should build this on top of Text, or where we could use String instead which would at least technically allow this to be in base). Cheers, Simon

* I think usage of MINIMAL pragmas could help a lot for your concerns about which of `display` or `displayBuilder` the user implements.

Good point :) Cheers, Simon

On Sat, Nov 15, 2014 at 09:38:14AM +0800, Simon Hengel wrote:

...

* I think usage of MINIMAL pragmas could help a lot for your concerns about which of `display` or `displayBuilder` the user implements.

I'm not sure this will work. We would need to specify something like

{} | {displayBuilder}

as minimal complete definition (where {} denotes the empty set), but I'm not aware of a way to specify the empty set with MINIMAL.

Unless somebody knows a solution, I would probably open a GHC ticket and propose to extend the MINIMAL pragma to allow for empty sets.

Please ignore what I said above. It does not make sense in multiple regards. The minimal complete definition for Display is the empty set. We have the invariant that if you define `display` you also have to define `displayBuilder`. If we would have a way to specify all sets of methods that gives us a complete+consistent definition, then that would be: {{}, {displayBuilder}, {displayBuilder, display}} I don know a way how to do that with MINIMAL, nor do I know a straight forward way to extend MINIMAL to accommodate this use case. Cheers.

Sounds good to me. The first half of the proposal has effectively unanimous support. -Edward On Fri, Nov 21, 2014 at 5:32 AM, Michael Snoyman wrote:

I realize it's a few days shy of the 2 week mark, but discussion has stopped, and there seems to be no objection to the first half of this proposal. Given that freeze is fast approaching for 7.10, I'd like to move ahead with implementation of this (which is admittedly an incredibly trivial patch).

I've created a Trac ticket for this:

https://ghc.haskell.org/trac/ghc/ticket/9822

Thanks all for the discussion.

On Mon Nov 10 2014 at 4:01:34 PM Michael Snoyman wrote:

...

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.

-- You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.