[Haskell-cafe] [ANN] text-display 0.0.1.0: A typeclass for user-facing output

Viktor Dukhovni ietf-dane at dukhovni.org
Tue Nov 2 20:44:30 UTC 2021


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.


More information about the Haskell-Cafe mailing list