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

[Thomas DuBuisson]

Jeff Heard proclaimed:
> There are multiple distinct reasons people use Show, and this gets
confusing.

This is exactly what I was getting at.  I see four uses being discussed:

1) Programmer readable / compiler parsable.

For this we have 'Show' and 'Read', but the community has a lack of
conformance on proper use of these classes.

Suggestion 1: Have "a == (read . show) a" as a mandatory QC test for all
exported data structures that have Read and Show instances within the
Haskell Platform packages.

2) Human readable format ('pretty').

The 'Pretty' type class is hidden in Test.PrettyPrint.HughesPJClass - much
as I admire the giants of FP I feel we shouldn't encode peoples names in
modules.  The whole 'Pretty' module heirarchy seems backward to me, the guts
are on the bottom (Text.PrettyPrint) and the high level API is hidden.

Suggestion 2: Alter the Pretty packages just a little, combine them, and
encourage people to use it.

3) "Network ready" string packing as mentioned by Donn Cave.

This one surprised me as I hadn't thought of a function termed 'str' or
'show' being used for binary encoding.  Obviously, we have Binary for just
this.

4) Casts comment:
> A parser function applied to a Haskell string representation of the second
form --- still (somewhat) readable, but also acceptable to ghci as input.

This odd middle ground is the only place I see package specific 'show*'
functions as appropriate.  OTOH, if its still valid Haskell I don't see why
this still can't be the Show type class, but the derivation will have to be
done manually or with a patched compiler.

forall m. (Mind m, View m ~ Maybe (Email Substance)) => Email a -> m -> View
m
(peoples views may vary and better be deterministic)

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081226/4c2028f6/attachment.htm