Discussion: adding displayException to Exception class

[Simon Peyton Jones]

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”!

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 at 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 <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141029/3d179ff2/attachment-0001.html>