
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