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.