Re: [core libraries] Re: Discussion: adding displayException to Exception class

I could definitely see adding a separate displayException method to Exception. +1 there. Removing Show as a superclass however is something we'd have to check, its the kind of thing where it'd silently affect some code that was just accepting the exception and printing it in a manner that could be worked around by using a pair of constraints, just like the change breaking up Num that Ian put through a few years back. If that is something folks *really* want to do, we could probably get there. If we did then you'd probably want class Typeable a => Exception a where ... displayException :: a -> String default displayException :: Show a => a -> String displayException = show which would let most of the existing code around it work, and only break the code that takes an exception blindly and prints it. Adding displayException strikes me as easy, and zero-pain. Removing Show on the other hand is something I'm somewhat less sanguine about, but not either for or against. -Edward On Wed, Oct 29, 2014 at 9:56 AM, Michael Sloan wrote:

Agreed!

I think there has been general consensus that when possible, Show should generate valid Haskell code. Suppose that you want to reproduce some bug where a specific set of functions are suspected. If there arguments are 'Show' instances, then you can output invocations of these functions to a file. This file can now be used as an executable, minimizable reproduction of the bug!

Honestly, I think 'Read' isn't all that important except for things like parsing numbers, very small applications. and prototypes. In practical code, you either end up using a serialization like binary or aeson, or writing your own pretty printer / parser. I'd rather have the property that 'show' results in code than the property that "read . show === id" (but certainly this is a nice property to have!).

Michael

On Wed, Oct 29, 2014 at 4:25 AM, Michael Snoyman wrote:

...

On Wed, Oct 29, 2014 at 1:18 PM, Simon Peyton Jones <

...

wrote:

...

If people want Show to generate something that can be copy/pasted into a Haskell source file, that’s a legitimate position. But please let’s not call it “serialisation”!

To be clear: people in this thread expressed the copy/paste concept. In

...

previous thread, serialization via Show/Read combination was definitely advocated. To hopefully flesh out all of the different positions I've seen expressed so far:

1. Express a valid Haskell expression for copy/paste reasons. 2. Express a valid Haskell expression to make it easy to determine the type of the exception thrown (even though that's not always enough information). 3. Express something that can be consumed by Read for easy serialization. 4. Print something which is meaningful to a Haskell developer. 5. Print something which would be meaningful to an end user.

I agree completely that (3) should be handled by Binary (or equivalent: ToJSON/FromJSON, cereal, Storable...). And it seems like (1) and (4) should overlap perfectly, with one little exception: there are some things (like a Handle, IO action or function) which could be printed but not copy-pasted. (2) would likely be handled better via Typeable, possibly with some extra plumbing for cases like extensible exceptions.

This is a great time for everyone to jump in with the use cases they care about that I've missed...

...

So we have:

1. Serialisation (use Binary)

2. Copy-pasteable into Haskell source file, but not necessarily human-readable (Show)

3. Human readable (Display)

It’s clearly a library-design issue whether (2) and (3) are worth separating. More classes, more code, but perhaps more expressiveness. What does the core libraries committee think? Personally I don’t see

(2) as

...

particularly important, but my opinion counts for little since I’m not a library author.

Simon

From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of Michael Snoyman Sent: 29 October 2014 11:02 To: Simon Peyton Jones Cc: libraries Subject: Re: Discussion: adding displayException to Exception class

On Wed, Oct 29, 2014 at 10:45 AM, Simon Peyton Jones wrote:

As I recently commented on this list[1], the Show typeclass is overloaded with multiple meanings (serialization, debug info, and user-friendly data display). The general consensus seems to be that the official semantics for Show should be for serialization (as paired up with Read).

Really? My instinct is otherwise: to use Show for human-readable display, and Binary for serialisation. Show/Read is a terribly inefficient serialisation format; as soon as you want to do it for real you end up with Binary anyway. And Show is already well established for human-readable purposes – that was one of its primary original purposes.

Simon

My weak vote in that thread went towards Show for human-readable display, but there was some quite harsh objection to that position. In this

simonpj@microsoft.com> the thread

...

...

too you can see people wanting a direct encoding of types which can be copy-pasted into a Haskell source file. Personally, I don't see much need for that, and especially given the new ability to essentially auto-derive Binary instances (via Generic), Show/Read serialization seems fairly pointless.

Nonetheless, making a proposal that doesn't enforce a changed semantics on the Show typeclass seems like the path of least resistance. If others want to jump back into the previous topic and try to hammer down the ideal usage of the Show typeclass, I'm happy to participate in that discussion too.

Michael

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

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