Discussion: adding displayException to Exception class

Michael Snoyman michael at snoyman.com
Wed Oct 29 11:25:07 UTC 2014


On Wed, Oct 29, 2014 at 1:18 PM, Simon Peyton Jones <simonpj at microsoft.com>
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 the
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 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> 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/9847bcb8/attachment.html>


More information about the Libraries mailing list