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