[Haskell] Conceptual overloading of show?

[Graham Klyne]

I raise a topic that has occurred to me repeatedly during my time with 
Haskell.  I am prompted to do so by a discussion in another place, where a 
significant (and, apparently, recurring) concern about the use and abuse of 
Java's toString() function is being raised.

It seems to me that there are (at least) two important uses for a function 
like 'show', which may sometimes have very different requirements:

(1) creation of some human-readable representation of a value, which may or 
may not contain sufficient information to reconstruct the value, and

(2) creation of a textual serialization of a value from which the value can 
subsequently be recreated.

I find it's not always entirely clear which of these 'show' is intended to 
be:  its pairing with 'read', and the way that String values are formatted 
including quotes suggests that it is intended to be a case of 
(2).  Language in the Haskell report also strongly gives this impression.

But in other situations, 'show' is commonly used in the sense of (1).  For 
example, in the Haskell report, section 7.1, (print function) the Show 
class is used to create output that is specifically intended for user 
consumption ("the standard output device (this is normally the user's 
terminal)").

Where this leads is that I think there should be *two* common 
value-to-string type classes, one of which is reversible (in the sense that 
the output of show is intended to be consumable by read), and another that 
is not required to be reversible and provides output for human 
consumption.  E.g., let's call the new class 'Format':

class Format a where
     format     :: a -> String
     formatList :: [a] -> String

instance Format Int where
     format       = show
     formatList x = showList x []

instance Format Char where
     format c   = [c]
     formatList = id

In many cases, format and show might be the same, built there would be no 
requirement for an instance for an instance of Format to be an instance of 
Show, or vice versa.  A practical version of format should probably provide 
for operation via ShowS values, but I don't currently think an equivalent 
to showsPrec would be necessary.

#g


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact