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