[Haskell-cafe] Don't make 'show*' functions

[ajb at spamcop.net]

G'day all.

Quoting Jeff Heard <jefferson.r.heard at gmail.com>:

> I don't think that making Show a type class was a mistake.

I don't either.  Two main reasons:

1. [Char] should not be shown ['l','i','k','e',' ','t','h','i','s'].

2. Default implementations of Show can break abstractions by leaking
    implementation details.

> I think
> that we have long since overloaded the meaning of Show and made it
> ambiguous.  There are multiple distinct reasons people use Show, and
> this gets confusing.  It would be good if we as a community tried to
> nail down these different meanings that people tend to attach to Show
> and fork out new type classes that each encompass those meanings.
> Text is useful and often ignored as a means of debugging, inspecting,
> logging, and serializing.

I tend to agree.  Some thoughts:

- Show is what print outputs and what GHCi reports.  Therefore, to most
   programmers, it's primarily for human-readability regardless of what
   the standard says.

- Read is barely useful as-is.  Don't get me wrong; the "read" function
   has a very handy interface, especially if all you need is to convert
   a String into an Integer.  But I'd wager that the majority of the most
   expert of expert Haskellers couldn't write a custom Read instance
   without constantly referring to the documentation and/or example code.
   In addition, very few people are aware of the performance characteristics
   of "reads".

- If you want serialisation and deserialisation, Show and Read are
   poorly-suited for it.  A real solution requires handling tricky
   cases like versioning, redundancy (e.g. computed fields), smart
   constructors etc.

- If what you actually want is parsing and/or pretty-printing, we have
   some great solutions for that.

Cheers,
Andrew Bromage