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

[Jonathan Cast]

On Fri, 2008-12-26 at 13:55 -0600, Jeff Heard wrote:
> I don't think that making Show a type class was a mistake.  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.

True.  Although I predict finding a description of a function for doing
any/all of the above which is precise enough that there is guaranteed to
be a *single* unique such function of type tau -> String, for each type
tau, will be difficult.

> Off the top of my head, I would say that the traditional meaning of
> Show could be changed to Serial,

The traditional meaning of Show comes from the fact that Hugs/ghci use
it, right?  So why do they do that?  It's not hard to come up with
scenarios (involving qualified import of modules, say, which is
considered good practice) where the result of Show is *not* acceptable
as input to ghci.  That is, where typing an expression at the ghci
prompt and then cutting-and-pasting the response back in gives a syntax
error.  (Data.Map, for example).

>  where serial encompasses both Read
> and Show -- possibly we could find a more efficient read function,
> several have been proposed.  Then a separate class could be made for
> HumanReadable (or Loggable) where the point would bet that we write
> something that can be read by humans without conforming to a
> particular grammar that Haskell could read back in.

When I work with my (forthcoming) interpreter, depending on my mood, I
may want to see an expression in any of three forms:

* The derived Show instance (yes, sometimes it's useful)
* The pretty-printed form of the expression
* A parser function applied to a Haskell string representation of the
second form --- still (somewhat) readable, but also acceptable to ghci
as input.

Which version do I make the instance of which class?

(In fact, I *do* import modules qualified, internally within my
interpreter, so the derived Show instance does not produce acceptable
input for ghci, but the application listed third does.)

jcc