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

[Simon Hengel]

> > I created an initial draft:
> >
> >     https://github.com/sol/display/blob/master/src/Data/Display.hs
> >
> >
> Is this intended to be a standalone library, or part of text (or some other
> package?).

I would assume a separate package, but if we manage to foster consensus
and if there is a strong vote for it, then I would be more than happy to
get it merged into text.

> > I named the builder version `displayBuilder` as I could not come up with
> > any better name (suggestions much appreciated!).
> >
> > In addition, I think the `display` method has to be outside of the
> > class.  Otherwise, if somebody defines `display` he end up with the
> > default implementation of `displayBuilder` (which is based on show and
> > may not be what is intended).  Any input on that?
> >
> >
> I don't think this is a good enough reason to avoid a possible
> optimization. I'd recommend documenting this aspect of the typeclass
> thoroughly, and then let people shoot themselves in the foot if desired.

Is this about avoiding the intermediate Builder?  If so, I think we can
achieve this with rewrite rules, e.g.:

    {-# RULES "display/Text" display = id #-}
    {-# RULES "display/String" display = fromString #-}

I'm still puzzled whether there are other use cases where it would be
beneficial to have `display` in the class.

BTW, one nice thing that I think we can do if we do not have `display`
in the class is providing versions for strict and lazy text [1].
Technically I think this is also possible if `display` is part of the
class definition, but then you run into name clashes if you want to
export the full class from both Data.Display and Data.Display.Lazy.

> PS: I just saw Greg's email, I'd like to +1 his questions,
> clarification is good.

Ok, I'll add my perspective on that branch of the discussion ;).

Cheers,
Simon

[1] https://github.com/sol/display/pull/1/files