On Tue, Nov 02, 2021 at 09:06:22PM +0100, Hécate wrote:
Hi everyone, I am proud to release the first version of text-display¹, a typeclass for user-facing output.
Looks cool. Thanks! A quick typo fix in the docs: s/decude/decode/
```haskell {-# LANGUAGE DerivingVia #-} data AutomaticallyDerived = AD -- We derive 'Show' deriving Show -- We take advantage of the 'Show' instance to derive 'Display' from it deriving Display via (ShowInstance AutomaticallyDerived) ```
This is a cool approach to reconciling Show with Display! I have a related question. In a DNS library I'm working on the "presentation form" of all resource records is ASCII octet strings, not UTF-8 text. I was building a similar "Present" type class that renders DNS resource records as (ASCII) ByteStrings, and uses ByteString builders for efficiency. With Text now moving to UTF8, which subsumes ASCII, I could perhaps just switch to using "display" instead and output Text? One thing I'm not sure about is how to embed any existing ByteString builders that are guaranteed to produce UTF-8 output as Text builders (given the new UTF-8 Text representation) without materialising the intermediate ByteString. It would cool if either Text or ByteString provided a mechanism to execute a ByteString builder as a Text builder (with a caveat that this is only valid for ASCII content). One potential application is that iproute now has an efficient ByteString Builder mapping IPv4 and IPv6 addresses to their ASCII forms (which is substantially faster than e.g. typical C-library inet_pton). If I want to "display" IPv[46] addresses efficiently as part of larger output streams (i.e. use display builders), how would I get a Text Builder from a ByteString builder without "needless" allocation and copying? I'd prefer to avoid cloning the ByteString builder code in iproute to produce a parallel Text builder implementation, though that could be a last resort... -- Viktor.