[Haskell] Conceptual overloading of show?
gk at ninebynine.org
Thu Nov 11 07:41:15 EST 2004
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
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.
More information about the Haskell