Discussion: adding displayException to Exception class

[Niklas Hambüchen]

> 1. Serialisation (use Binary)
> 2. Copy-pasteable into Haskell source file, but not necessarily
>    human-readable (Show)
> 3. Human readable (Display)

I agree a lot to this.

While for Simon 2 doesn't seem to be useful, Show representing the
Haskell value and its structure as much as possible is super useful when
debugging business logic code, especially when it was written by other
people years ago.

It's rarely done, but when you actually do use ghci with break points,
Show is a very useful (and necessary) tool to see what's in your values,
and you wish every type had a Show instance - even better if it's a
derived one.

IMO, using Show for pretty printing defeats a lot of the above purpose,
and thus I welcome any effort to separate Show and Display things (so +1).

Yes, sometimes the Show instances aren't as nice as we would like them
to be (e.g. fromList for Sets as Chris mentioned), but despite these
unhappy cases, the debugging/programmer oriented nature of Show seems
fundamental to me.

There seems to be full consensus that Show (and any String based
functionality) isn't a good idea for "serialisation as part of the
program functionality". We just have to be careful to distinguish this
from "serialisation for the programmer/debugging", since when people say
just "serialisation" they can mean either.

Regarding Jeremy's proposed rules for Read/Show, I would put them in
different order:

  1. the Show instance should always come as close to valid Haskell
     as possible
  2. if it is possible to write a Read instance, write (best derive)
     one, otherwise don't (e.g. if your thing contains IORefs)