[RFC] Support Unicode characters in instance Show String

[Oleg Grenrus]

GHC Manual: Using a custom interactive printing function [1]

    Prelude Data.Char> "foo"
    "foo"
    Prelude Data.Char> let myprint=putStrLn . map toUpper . show
    Prelude Data.Char> :set -interactive-print myprint
    Prelude Data.Char> "foo"
    "FOO"

I remember some people using e.g. pretty-show or pretty-simple packages
with great success.

No need to change anything in base, just make users aware of a configuration
possibility.

Also this allows people to actually experiment and come up with good design
for a library specifically tailored for interactive printing.  For example,
Python's repr implementations are often configurable, as in pandas AFAIU,
as one-size doesn't fit all tastes. (Neat case for implicit params in
Haskell?)

I'm not in support of a new class in base, without prior art.
Changing stuff in base is difficult, better to get it (quite) right.

I'm undecided on the original proposal itself, I'll wait for OP to answer my
questions first, and amend the proposal if needed.

[1]:
https://downloads.haskell.org/~ghc/9.0.1/docs/html/users_guide/ghci.html#using-a-custom-interactive-printing-function

On 8.7.2021 22.21, Tikhon Jelvis wrote:
> 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 <mailto: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 <mailto:Libraries at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
>
>
> _______________________________________________
> 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/af1be9fa/attachment.html>