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