[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 12:38:02 PM Simon Hengel <sol at typeful.net> wrote:

> > > 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.
>
> Just to properly understand that point, in that cases I could still try
> to remedy this with rewrite rules (with the limitations you mentioned
> above), right?  Or is there an other aspect to it?
>
>
That's correct.


> > > 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?
>
> That would leave us with three methods, say:
>
>     class Display a where
>       displayBuilder :: a -> Builder
>       default displayBuilder :: Show a => a -> Builder
>       displayBuilder = fromString . show
>
>       displayLazy :: a -> LT.Text
>       displayLazy = toLazyText . displayBuilder
>
>       display :: a -> Text
>       display = toStrict . displayLazy
>
> Which comes with the big warning attached that if you define any of
> display/displayLazy, you also have to define displayBuilder.
>
> I guess alternatively we could also put the default signature on
> `display`, where `display` would then always be required.
>
> So as I understand it, the dowside is that a user can break the
> invariants between display/displayLazy/displayBuilder by accident.
>
> The up side is that it may be more efficient.
>
> I have no picture on how big the potential performance gain would be.
> If it is non-noticable for most practical cases, I would lean towards
> the simpler solution.
>
> An other direction could be to challenge whether we actually need the
> Builder version at all.  I see that this is useful if we plan to apply
> `displayBuilder` recursively.  If that use case is not prevalent, using
> Builder may also be less crucial (which again posses the question to me
> whether we really should build this on top of Text, or where we could
> use String instead which would at least technically allow this to be in
> base).
>
>
>
If we had to lose *something*, I'd rather lose the `display` and
`displayLazy` versions, not `displayBuilder`. But let me throw out some
random thoughts;

* I'm not really in favor of putting the lazy version in the typeclass, I
was simply addressing the concern you raised. I find it hard to believe
that there would be real cases where someone would want to override it.
*  I think usage of MINIMAL pragmas could help a lot for your concerns
about which of `display` or `displayBuilder` the user implements.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141111/7bad9db5/attachment-0001.html>