<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>> I don't see a plausible path of getting most libraries that
      implement<br>
      > `Show` to start implemeting a second parallel class for
      friendly display.<br>
      <br>
      * Extensive publicity of this typeclass in community (social
      media, etc)<br>
      * Stock deriving (implemented by GHC & the CLC)<br>
      * First-class place in documentation (Documentation Task Force of
      the HF)<br>
      * Coordinated effort with popular libraries to implement its
      adoption (CLC + stakeholders)<br>
      * Maybe a code-modding script using <a moz-do-not-send="true"
        href="https://hackage.haskell.org/package/retrie">retrie</a>.<br>
      <br>
      We will have to work as a community on that one but I am convinced
      that this is doable. <br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">Le 08/07/2021 à 21:18, Viktor Dukhovni
      a écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:YOdPjeKrF1xUK9oS@straasha.imrryr.org">
      <pre class="moz-quote-pre" wrap="">On Thu, Jul 08, 2021 at 09:02:29PM +0200, Hécate wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap=""> From what I can see from the various typeclasses that exist:

</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Sadly, no new or extant alternative type classes can address the
problem, simply because they're NOT `Show`, which is the default
interface for inspecting the content of a term, and so is the only
one at all likely to be available for the terms of interest.

Yes, we should also consider having more type classes for presentation
in forms other than compiler-friendly source syntax.

Thus, e.g. for DNS data, one might have `Show` for debugging, but
`Present` for textual presentations of DNS resource records specified in
the multitude of DNS-related RFCs and used as the input syntax in DNS
zone files.  (Thus a DNS RR would have a binary wire form, an ASCII
ByteString presentation form, a `Show` instance that exposes all the
constructors, ..., and in the case of domain names also a U-label
form for display of domain names to users more comfortable with the
native script).

Multiple applicable serialisation formats are to be expected, and yet I
think that `Show` should still avoid escaping unicode printable text...

I don't see a plausible path of getting most libraries that implement
`Show` to start implemeting a second parallel class for friendly
display.

Unless you're thinking overlapping  instances:

    instance Show a => Display a where
        display = show

    instance Display String where
        display = displayString

</pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: <a class="moz-txt-link-freetext" href="https://glitchbra.in">https://glitchbra.in</a>
RUN: BSD</pre>
  </body>
</html>