Conceptual overloading of show?
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
Graham Klyne <gk@ninebynine.org> writes:
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.
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':
This is similar Python's str() (string) vs repr() (representation) functions. Python's repr is designed to work like "read . show = id" such that eval(repr(x)) == x and repr also makes a string (only ASCII as far as I know). But maybe this doesn't have to be limited to strings? I've wanted "deriving WebPublish" and at some level that also involves a "show as html/xml" My WebPublish ideas would be easier with "readXML.showXML == id" Dominic Steinitz' ASN.1 code might be easier with readASN1/showASN1 I get the feeling there's a higher-level pattern here, but I don't how to capture it with Haskell's Read/Show classes. Some discussion on #haskell turned up: Björn Bringert mentioned the THDeriveXmlRpcType module in his XmlRpc library. So maybe Show can be parameterized on various 'transports' ? Philippa Cowderoy suggested "Show signal carrier" instead of the present "Show signal [implicit String]" Maybe deriving (Show Transport) like deriving (Show XmlRpc)? Any thoughts along these lines? -- Shae Matijs Erisson - Programmer - http://www.ScannedInAvian.org/ "I will, as we say in rock 'n' roll, run until the wheels come off, because I love what I do." -- David Crosby
Shae, Thank you for noticing the Python parallel... I'd forgotten about that. I like the principle of parameterizing Show to allow for different encoding environments (indeed, I had wondered as I was writing my earlier message if the two cases were really sufficient). Indeed, in the application area that interests me (Semantic Web) it could be beneficial to have different encoding options corresponding to different serializations of RDF (e.g. RDF/XML and Notation3). But I also wonder if this adds complexity (of ideas, of not implementation) that really doesn't belong in a very widely used generic library facility. #g -- At 17:27 11/11/04 +0100, Shae Matijs Erisson wrote:
Graham Klyne <gk@ninebynine.org> writes:
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.
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':
This is similar Python's str() (string) vs repr() (representation) functions.
Python's repr is designed to work like "read . show = id" such that eval(repr(x)) == x and repr also makes a string (only ASCII as far as I know).
But maybe this doesn't have to be limited to strings? I've wanted "deriving WebPublish" and at some level that also involves a "show as html/xml" My WebPublish ideas would be easier with "readXML.showXML == id" Dominic Steinitz' ASN.1 code might be easier with readASN1/showASN1
I get the feeling there's a higher-level pattern here, but I don't how to capture it with Haskell's Read/Show classes.
Some discussion on #haskell turned up:
Björn Bringert mentioned the THDeriveXmlRpcType module in his XmlRpc library. So maybe Show can be parameterized on various 'transports' ? Philippa Cowderoy suggested "Show signal carrier" instead of the present "Show signal [implicit String]" Maybe deriving (Show Transport) like deriving (Show XmlRpc)?
Any thoughts along these lines? -- Shae Matijs Erisson - Programmer - http://www.ScannedInAvian.org/ "I will, as we say in rock 'n' roll, run until the wheels come off, because I love what I do." -- David Crosby
------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
participants (2)
-
Graham Klyne -
Shae Matijs Erisson