custom Format class (Was: [RFC] Support Unicode characters in instance Show String)

Viktor Dukhovni ietf-dane at dukhovni.org
Thu Jul 8 21:37:51 UTC 2021


On Thu, Jul 08, 2021 at 11:07:36PM +0200, H├ęcate wrote:

> You can literally piggyback on Show's machinery for generic deriving?
> I don't understand the issue here.  If the output is not easily-read
> by humans, then implement the instance yourself?

Indeed a `Render` (module bikeshedding the name) class can be derived
in much the same way as `Show`, but might not be as friendly in many
cases, because generically it would emit constructor and field names
that might be omitted in a more friendly rendition of the structure.

So `Render` would warrant a specialised instance in more cases.

One might perhaps `render` a date in ISO 8601 format, skipping the
constructor names.

If, for example, it was decided that a DNS Resource Record should
`render` to its RFC Presentation form, then one might want to render a
list of resource records (an RRSet) by just joining newline separated
strings:

    > putStrLn $ render $
        [ { rname = "example.com."
          , rclass = IN
          , rdata = RData { T_A "192.0.2.1" }
        , { rname = "example.com."
          , rclass = IN
          , rdata = RData { T_A "127.0.0.1" } ]
    example.com. IN A 192.0.2.1
    example.com. IN A 127.0.0.1
    >

rather than as:

    ["example.com. IN A 192.0.2.1","example.com. IN A 127.0.0.1"]

taking advantage of the possibility of custom presentation of lists.

It may be worth noting that on a smaller, incremental scale, once
`Render` is established, there would be incentives to fix some of
the non-lawful `Show` instances, which would introduce transient
breakage for the consumers of the affected packages.

-- 
    Viktor.


More information about the Libraries mailing list