Parameterized Show? was Re: [Haskell] Conceptual overloading of show?

[Graham Klyne]

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 at 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