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

On Mon, Nov 10, 2014 at 10:51 AM, Evan Laforge wrote:

On Mon, Nov 10, 2014 at 10:25 AM, Greg Weber wrote:

...

What is the goal of this project? To pretty-print output? Or to be a slightly friendlier version of Show? To put it another way, what happens with more complicated structures? As an example, what should the output be for this type [[String]] ?

I've long used a Pretty class, which outputs a Doc from a pretty printing library. That way it can be flattened into one line or wrapped, depending on context. Most of the readability comes from the layout, and the rest comes from how I can omit "less important" data or use non-haskell syntax (e.g. {k: v} for maps). So for me a Display class that doesn't include layout wouldn't be very useful.

This is what I was hinting at.

I include all data in Show (and usually derive it), which means that it's valid syntax and I automatically parse and then format it with Language.Haskell.Pretty.

I don't know if this is applicable to a general purpose Display class, because then it would have to pick a pretty printing library, which means it's making choices about layout and formatting, which means it's not really universal. E.g. I currently use HughesPJ but modified to avoid piling up on the right margin, but having been meaning for a long time to switch to an indentation based formatter that uses Text.

I am wondering if it is possible to have a standard code display data type for marking up code with display information that can then be converted to work with different pretty-printing libraries. Perhaps this current project would follow under your second principle though of omitting less important data and using non-Haskell syntax and it could be used by another project that deals with the layout issue. Still, as it stands, I don't think that will work. A display type for a Map really needs to specify how a key/value pairing is displayed, and how the Map container is displayed, and needs to hand off those instructions to a layout engine. The existing Show actually fares better because it is parse-able Haskell code. That way libraries such as groom exist which know how to parse it and can change the layout.

Also, I use the showList hack. It works.