<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>From what I can see from the various typeclasses that exist:<br>
<br>
HaTeX's <a moz-do-not-send="true"
href="https://hackage.haskell.org/package/HaTeX-3.22.3.0/docs/Text-LaTeX-Base-Render.html#t:Render">Render</a>:<br>
<br>
> Class of values that can be transformed to <code><a
href="https://hackage.haskell.org/package/HaTeX-3.22.3.0/docs/Text-LaTeX-Base-Render.html#t:Text"
title="Text.LaTeX.Base.Render">Text</a></code>.
<br>
</p>
<p>core-text's <a moz-do-not-send="true"
href="https://hackage.haskell.org/package/core-text-0.3.0.0/docs/Core-Text-Utilities.html#t:Render">Render</a>:<br>
<br>
> Types which can be rendered "prettily", that is, formatted by
a pretty printer and embossed with beautiful ANSI colours when
printed to the terminal.</p>
<p>ttc's <a moz-do-not-send="true"
href="https://hackage.haskell.org/package/ttc-1.1.0.1/docs/Data-TTC.html#t:Render">Render</a>:</p>
<p>> The Render type class renders a data type as a textual data
type.</p>
<p>When defining such classes, people don't seem to enforce much,
and on the opposite seem to loosely define the requirements,
allowing for ANSI colours for instance. Since we have a mechanism
to produce our own instances through newtype wrappers and use
Generalised Newtype Deriving or Deriving Via, I don't see much of
a problem at this point (of course I only ask to be proven wrong).
<br>
<br>
One example in another language is Rust, which has the <a
moz-do-not-send="true"
href="https://doc.rust-lang.org/core/fmt/trait.Debug.html">Debug</a>
and <a moz-do-not-send="true"
href="https://doc.rust-lang.org/core/fmt/trait.Display.html">Display</a>
traits, Debug being akin to our Show, and Display having the
following property<br>
<br>
> Display is similar to Debug, but Display is for user-facing
output, and so cannot be derived.<br>
<br>
It also interesting to note that these traits belong to a <a
moz-do-not-send="true"
href="https://doc.rust-lang.org/core/fmt/index.html">wider
family of formatting traits</a> used with their built-in syntax
of formatting (Binary, Debug, Lower & Upper Hex, Display,
Octal, Write, etc).</p>
<p>–––<br>
<br>
Henning, you are right, `printf` does exist, and it looks pretty
rich in terms of features and customisation. I acknowledge that
not using it is mostly a cultural matter, and that it can be fixed
by improving our current pedagogical material. If we decide as a
community that a typeclass is actually not the proper tool to get
away from Show instances, then I will welcome with open arms blog
posts & tutorials to guide our community towards this
solution, and promote them.<br>
</p>
<div class="moz-cite-prefix">Le 08/07/2021 à 20:25, Henning
Thielemann a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:9b3f6ab7-5d62-e173-9bcf-ef4fa4bc85e0@henning-thielemann.de">
<br>
On Thu, 8 Jul 2021, Hécate wrote:
<br>
<br>
<blockquote type="cite">I guess this is the perfect time to come
up with a Render typeclass that targets end-users rather than
satisfying 'read . show = id'.
<br>
<br>
chessai: Could the CLC appoint someone to start working on
something? This would be pretty useful to unify the ecosystem
(instead of having custom Outputable, Render, etc).
<br>
</blockquote>
<br>
The question is, whether such a one-fits-all library actually
serves the needs of the users. Actually there is already 'printf'
which is intended for formatting end-user output. You can write
your own PrintfArg instances. Today I am using custom Format
classes per project.<br>
</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>