[Haskell-cafe] Don't make 'show*' functions

Donn Cave donn at avvanta.com
Fri Dec 26 17:23:29 EST 2008

Quoth brian <brianchina60221 at gmail.com>:
| On Fri, Dec 26, 2008 at 1:55 PM, Jeff Heard <jefferson.r.heard at gmail.com> wrote:
|> Off the top of my head, I would say that the traditional meaning of
|> Show could be changed to Serial, 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.
| +1. 'Show' sounds like it's for what Java 'toString' and Ruby 'to_s',
| etc., do, and that's not right.

To be fair, this seems to be a natural ambiguity with string representation.

Python kind of blundered into it around 2.0, when someone decided to
"fix" the __repr__ function for floating point to display the best
decimal value, where it had until then used a rounded value.  So users
were confounded to see for example that 1.0 - 0.1 is 0.90000000000000002,
instead of 0.9, but that does make some sense if __repr__ is to be used
for string marshalling.

Python has two string representation functions, __str__ and __repr__.
The documentation of these two functions is a long standing problem that
will probably never be resolved.  If as proposed above there had also
been a third function that is strictly about marshalling, that might
have made it a little easier to focus on the difference betweeen str
and repr, where unfortunately the documentation has confused the issue
with ambiguous notions like friendliness.

For me, "str" is about conversion to string data, where a data type contains
or represents string data.  Conversion implies loss.  For example, an
HTML or RFC822 header would convert to its "wire" data.  But that's at
odds with expectations for numeric types, for example - I'd make str(65)
= 'A', but of course it's actually '65'.

"repr" portrays the value as a Python object - what you would see for
example from the interactive interpreter.  Since Python objects are
commonly "in the IO monad", there are all kinds of cases where the
repr value can't fully marshal the object.


More information about the Haskell-Cafe mailing list