Data.Display - Textual representation of Haskell values (was Re: PROPOSAL: Add displayException to Exception typeclass)

[Simon Hengel]

On Mon, Nov 10, 2014 at 10:25:45AM -0800, Greg Weber wrote:
> What is the goal of this project? To pretty-print output? Or to be a
> slightly friendlier version of Show?

>From my perspective display would be akin to str()/#to_s in Python/Ruby.
So I was not thinking to tackle pretty-printing in general.

My *very personal* main use case, that I don't see other good solutions
for, is string interpolation.  Currently I have a crude hack in
interpolate [1] that does the right thing for String, Text and many
prelude types (see also [2] if you are curious).

But even more important to me is that we come up with something that is
general, has minimal dependencies and is not controversial, so that
people are willing to depend on it and provide instances.

If there is a way to "add extension points" (what ever that may mean)
for pretty-printing or do something else that is useful in the context
of pretty-printing libraries, I think we should discuss it.  But it's
not my main objective.

> To put it another way, what happens with more complicated structures?
> As an example, what should the output be for this type [[String]] ?
> 
> [["abc", "def"], ["ghi"], ["jkl"]]
> 
> Or
> 
> [  ["abc", "def"]
>  , ["ghi"]
>  , ["jkl"]
> ]

In case of doubt I would lean towards falling back to `show`.  That
would probably mean

    [["abc","def"],["ghi"],["jkl"]]

for consistency with `show` (even though personally I prefer to have a
space after the comma).  By adding `displayList` to the class,
individual instances would still be free to override this behavior.

On the implementation side, I think we could either use showList and put
that into a builder _or_ use show on all the list elements and construct
the final "displayed" list output using a builder.  The second may be
more efficient, but for nested lists show would still be invoked on
lists (I think we have a similar situation for other nested data types,
unless we invoke displayBuilder recursively, which I think gives
surprising results).

I'm not entirely sure.  An other option could be to just skip support
for lists, not sure?

Cheers,
Simon

[1] https://github.com/sol/interpolate/blob/9be1f6d15722c58e467e7ebc0cb6dc6fb2c4f5e0/src/Data/String/Interpolate/Internal/Util.hs#L9
[2] http://sol.github.io/interpolate-talk/