[RFC] Support Unicode characters in instance Show String

[Tikhon Jelvis]

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

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.

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.

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.

On Thu, Jul 8, 2021 at 11:27 AM Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> On Thu, 8 Jul 2021, Hécate wrote:
>
> > I guess this is the perfect time to come up with a Render typeclass that
> > targets end-users rather than satisfying 'read . show = id'.
> >
> > 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).
>
> 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._______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20210708/d2a57764/attachment.html>