My experience is that whenever someone writes a "helpful" Show instance it winds up anything but.

Why?

What happens when you print a list of them, or they occur deeper in a larger structure?

Invariably I wind up with things like a bag of your exceptions in an async exception wrapper or someone's position type in my data structure -- I first noticed this when I was working with parsec.

I'd stick source positions in my data types, but Parsec was helpful:
instance Show SourcePos where
  show (SourcePos name line column)
    | null name = showLineColumn
    | otherwise = "\"" ++ name ++ "\" " ++ showLineColumn
    where
      showLineColumn    = "(line " ++ show line ++
                          ", column " ++ show column ++
                          ")"
.. and with that now users can't made hide nor hair out of syntax tree terms, etc.

"Helpful" Show instances are not compositional.

-Edward

On Wed, Oct 29, 2014 at 9:22 PM, Niklas Hambüchen <mail@nh2.me> wrote:
> 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)

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