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

[Hécate]

 > 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.

GHC releases frequently fix situations where code that was previously 
accepted will be rejected, so it feels normal that we decide to fix 
unlawful Show instances while providing a more adapted solution for 
human-readable outputs. :)

Le 08/07/2021 à 23:37, Viktor Dukhovni a écrit :
> 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.
>
-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD