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

[Greg Weber]

On Mon, Nov 10, 2014 at 10:51 AM, Evan Laforge <qdunkan at gmail.com> wrote:

> On Mon, Nov 10, 2014 at 10:25 AM, Greg Weber <greg at gregweber.info> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141110/46d25f29/attachment-0001.html>