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

[Michael Snoyman]

On Tue Nov 11 2014 at 5:29:52 AM Simon Hengel <sol at typeful.net> wrote:

> > > 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've never really been a fan of using RULES in this way. It makes it more
difficult for someone writing their own instance to see that they can
provide an optimized implementation, and rewrite rules don't always fire
reliably (e.g., more polymorphic code without aggressive inlining could
confuse this).


> I'm still puzzled whether there are other use cases where it would be
> beneficial to have `display` in the class.
>
>
Any case where there are functions already defined in terms of Text that
`displayBuilder` is simply wrapping.


> 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.
>
>
Why not have `display` and `displayLazy`, or something like that? If
someone is really convinced they need to have the function be called
`display` for lazy text, you can re-export it under that name from
`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
>
> --
> You received this message because you are subscribed to the Google Groups
> "haskell-core-libraries" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to haskell-core-libraries+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141111/d1b19310/attachment-0001.html>