Thomas DuBuisson wrote:
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:
Indeed, though I think the situation is even worse. It seems to me that
there are a number of cross-purposes for the Read+Show classes. The two
main questions at stake are:
A) Who/what is the audience?
Common answers:
1) The human user on the other side of the terminal
2) The human developer trying to debug their work
3) The compiler, a la cut&paste
4) A program on the other end of the wire/disk/flux capacitor
B) What is the resolution/detail?
Common answers:
1) All the gory details
2) Enough for a human to get the big picture
3) Enough for a computer to get the right value
The @a == (read . show) a@ interpretation is in A3/B1 territory, or
A3/B3 if smart constructors are used. The GHCi and Hugs REPL are
generally in A2/B1, or A1/B2 if we're trying to abstract away from the
concrete implementation. The showTrie function mentioned at the outset
of this thread is firmly in the A2/B2 category and is not intended for
end users at all.
Clearly not all of these combinations can be serviced by a single class
or pair of classes. Many of the combinations can themselves be broken
down further (how much detail is "enough" to get the big picture?).
One of the things which has always disappointed me about the Read+Show
classes is that they elide the profound difference between A1 and A2.
Printing out a value for human consumption is entirely different than
printing it out for debugging. The A3 compromise only serves to muddy
things further and brings on the spectre of A4. For complex
datastructures like Map, IntMap, and Trie there are many details stored
in the structure which end users need not or should not know about; but
these details are essential to the developers to ensure their code is
doing what they think it should be. Similarly, for these large
datastructures there is a profound difference in resolution between a
derived Show class and an ASCII-art rendering of the tree. For small
values ---and when you don't trust your tree drawer--- the derived
instance is just what you want, but it quickly becomes unreadable for
all but the most trivial examples.
Given the enormous design space involved here, there is no tractable
answer that will cover everything. People have been working on user
interfaces and data visualization for years, and no perfect answer has
been found. But that doesn't mean we can't make progress. I agree with
Thomas DuBuisson's suggestions and have rephrased them below, along with
three new ones of my own.
Proposal 1: Combine Read and Show into a single class, "enforcing" @a ==
(read . show) a@ with the intention of capturing A3/B1 or A3/B3. While
this may be serviceable for A1 or A2 uses, the intention of the class
should be made clear that it is for A3. Presumably some solution should
be found for types which can be read or shown but not both.
Proposal 2: Clean up Text.PrettyPrint.HughesPJ and market it heavily for
covering code-oriented aspects of A1. Other visualizations like charts,
graphs, or trees should be relegated elsewhere.
Proposal 3: Add a generic Lisp pretty printer function to convert from
the output of Proposal 1 towards output like Proposal 2. Dealing with
operators makes it trickier than Lisp, but most datastructures lack
operators. I'm sure this has already been written in Haskell by Yi
enthusiasts, and it should reduce the cost of getting people into using
Pretty.
Proposal 4: Write a generic function for taking recursive types and
printing them as a tree. Users should only need to serialize the "here"
content of each node, leaving it up to the generic function to add
spines and adequate spacing between nodes. This is for targeting A2/B2.
While it's a time-honored tradition to implement specialized versions of
this function to introduce people to recursion, making a standard
version for visualizing large datastructures would alleviate some of the
burden of what Show should be doing.
Proposal 5: Currently a main consumer of Show is the GHCi or Hugs REPL.
However, those are used both by end users and by developers, which leads
to the elision between A1 and A2. Provided the previous four proposals
are taken to heart, it would be nice if GHCi and Hugs had commands to
select which viewing mode (show, prettyShow, lispShow, treeShow) should
be used for each type. By default, when available prettyShow should be
favored over lispShow which is favored over show; but this behavior
could be changed on a type-by-type basis. There are complications here
regarding how to recurse for each element of a type, but they seem soluble.
--
Live well,
~wren
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
