<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>GHC Manual: Using a custom interactive printing function [1]<br>
<br>
Prelude Data.Char> "foo"<br>
"foo"<br>
Prelude Data.Char> let myprint=putStrLn . map toUpper .
show<br>
Prelude Data.Char> :set -interactive-print myprint<br>
Prelude Data.Char> "foo"<br>
"FOO"<br>
<br>
I remember some people using e.g. pretty-show or pretty-simple
packages<br>
with great success.<br>
<br>
No need to change anything in base, just make users aware of a
configuration<br>
possibility.<br>
<br>
Also this allows people to actually experiment and come up with
good design<br>
for a library specifically tailored for interactive printing. For
example,<br>
Python's repr implementations are often configurable, as in pandas
AFAIU,<br>
as one-size doesn't fit all tastes. (Neat case for implicit params
in Haskell?)<br>
<br>
I'm not in support of a new class in base, without prior art.<br>
Changing stuff in base is difficult, better to get it (quite)
right.<br>
<br>
I'm undecided on the original proposal itself, I'll wait for OP to
answer my<br>
questions first, and amend the proposal if needed.<br>
<br>
[1]:
<a class="moz-txt-link-freetext" href="https://downloads.haskell.org/~ghc/9.0.1/docs/html/users_guide/ghci.html#using-a-custom-interactive-printing-function">https://downloads.haskell.org/~ghc/9.0.1/docs/html/users_guide/ghci.html#using-a-custom-interactive-printing-function</a><br>
</p>
<div class="moz-cite-prefix">On 8.7.2021 22.21, Tikhon Jelvis wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJN5CV+OfaaK1i3wC4oyyoZg9GKzCPjSBEKrNVKHif5c7KCEyg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Let me second the idea of a Render class—it's something
I've wanted repeatedly. There is a clear tension between
Show's requirements and human-readable outputs: strings get
less readable, we can't summarize/truncate large values, it
can't handle functions...</div>
<div><br>
</div>
<div>At the same time, Show is special because it is ubiquitous.
We can derive Show automatically, and it's one of the few
classes we can expect almost every data type to implement.
Project-specific formatting classes cannot fulfill the same
role as Show; they require a non-trivial setup cost (which
especially compromises the beginner experience!) and they
cannot be used by tools and libraries that are not
project-specific. What can a library author do to make their
types more readable and usable to their users? Today the best
lever is the Show instance, which is why I've seen
substantially more "unlawful" Show instances in the wild
compared to any other base typeclass.</div>
<div><br>
</div>
<div>Other languages like Python and Rust have a similar split.
I've been doing a fair amount of data sciencey Python lately,
and I can tell you that the experience at the normal
interpreter (not even talking about Jupyter) is definitely
better than in Haskell because things like dataframes are
rendered in a human-readable way, formatted as a table and
truncated.</div>
<div><br>
</div>
<div>Having a human-readable class is a non-trivial proposal on
its own, and normally I wouldn't want to link it to a
different change. In this case, however, there is a clear
overlap: a new Render class lets us have two different
to-string behaviors in parallel, which solves the problem in a
similar way to the other alternatives proposed like a language
extension or changing GHCi.<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Jul 8, 2021 at 11:27
AM Henning Thielemann <<a
href="mailto:lemming@henning-thielemann.de"
moz-do-not-send="true">lemming@henning-thielemann.de</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On Thu, 8 Jul 2021, Hécate wrote:<br>
<br>
> I guess this is the perfect time to come up with a Render
typeclass that <br>
> targets end-users rather than satisfying 'read . show =
id'.<br>
><br>
> chessai: Could the CLC appoint someone to start working
on something? <br>
> This would be pretty useful to unify the ecosystem
(instead of having <br>
> custom Outputable, Render, etc).<br>
<br>
The question is, whether such a one-fits-all library actually
serves the <br>
needs of the users. Actually there is already 'printf' which
is intended <br>
for formatting end-user output. You can write your own
PrintfArg <br>
instances. Today I am using custom Format classes per
project._______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank"
moz-do-not-send="true">Libraries@haskell.org</a><br>
<a
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Libraries mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Libraries@haskell.org">Libraries@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a>
</pre>
</blockquote>
</body>
</html>