wren ng thornton schrieb:
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
no
2) The human developer trying to debug their work
yes
3) The compiler, a la cut&paste
yes
4) A program on the other end of the wire/disk/flux capacitor
no
B) What is the resolution/detail?
Common answers: 1) All the gory details
maybe
2) Enough for a human to get the big picture
no
3) Enough for a computer to get the right value
yes
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.
Hm, yes, there seems to be demand for debug-levels, even different ones for different libraries
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.
functions - If you have only one field in a record, which is of function type, you may use a dummy 'show' for it, but you cannot define a 'read'.
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.
... TeX, HTML, ...
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.
I think, that a user who uses GHCi becomes a developer. For me a user is someone who calls compiled Haskell programs.
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.
Yes it would be nice, if the showing in GHCi could be changed. Such that e.g. matrices are shown as grids. However, this can be currently done by passing the expression to a function which does the required formatting. I remember GSLMatrix had a function like (//) :: Matrix -> Precision -> IO () which let you write GSLMatrix> matrix // 2 /1.00 0.00\ \0.00 1.00/ I would not be surprised, if GHCi can already be configured to attach the (//2) automatically. I always think we need a type class which allows to give type specific options. However, the option type would functionally dependency on the type of the shown value, and thus the type class must be a multiparameter typeclass with functional dependencies. This way you can specify formatting options of the matrix (kind of parentheses) and its elements (precision, exponential style etc.).