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

[Edward Kmett]

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 at 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 at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141029/6c65746a/attachment.html>