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

[Henning Thielemann]

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.).