On 08/07/2021 17.53, Oleg Grenrus wrote: [--snip--]

78 out of 2819 tests failed (35.88s)

The use of Show in 'golden' test suites is interesting because Show doesn't really guarantee any real form of stability in its output. I guess Hyrum's Law applies here too. Anyway... just an idle observation. Obviously, breaking loads of test suites is going to be hard to swallow. Regards,

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). Le 08/07/2021 à 18:38, Bardur Arantsson a écrit :

On 08/07/2021 17.53, Oleg Grenrus wrote:

[--snip--]

...

78 out of 2819 tests failed (35.88s)

The use of Show in 'golden' test suites is interesting because Show doesn't really guarantee any real form of stability in its output.

I guess Hyrum's Law applies here too.

Anyway... just an idle observation. Obviously, breaking loads of test suites is going to be hard to swallow.

Regards,

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

From what I can see from the various typeclasses that exist: HaTeX's Render https://hackage.haskell.org/package/HaTeX-3.22.3.0/docs/Text-LaTeX-Base-Rend...:

Class of values that can be transformed to |Text https://hackage.haskell.org/package/HaTeX-3.22.3.0/docs/Text-LaTeX-Base-Rend...|.

Types which can be rendered "prettily", that is, formatted by a

core-text's Render https://hackage.haskell.org/package/core-text-0.3.0.0/docs/Core-Text-Utiliti...: pretty printer and embossed with beautiful ANSI colours when printed to the terminal. ttc's Render https://hackage.haskell.org/package/ttc-1.1.0.1/docs/Data-TTC.html#t:Render:

The Render type class renders a data type as a textual data type.

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). One example in another language is Rust, which has the Debug https://doc.rust-lang.org/core/fmt/trait.Debug.html and Display https://doc.rust-lang.org/core/fmt/trait.Display.html traits, Debug being akin to our Show, and Display having the following property

Display is similar to Debug, but Display is for user-facing output, and so cannot be derived.

It also interesting to note that these traits belong to a wider family of formatting traits https://doc.rust-lang.org/core/fmt/index.html used with their built-in syntax of formatting (Binary, Debug, Lower & Upper Hex, Display, Octal, Write, etc). ––– 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. Le 08/07/2021 à 20:25, Henning Thielemann a écrit :

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.

-- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

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

* Extensive publicity of this typeclass in community (social media, etc) * Stock deriving (implemented by GHC & the CLC) * First-class place in documentation (Documentation Task Force of the HF) * Coordinated effort with popular libraries to implement its adoption (CLC + stakeholders) * Maybe a code-modding script using retrie https://hackage.haskell.org/package/retrie. We will have to work as a community on that one but I am convinced that this is doable. Le 08/07/2021 à 21:18, Viktor Dukhovni a écrit :

On Thu, Jul 08, 2021 at 09:02:29PM +0200, Hécate wrote:

...

From what I can see from the various typeclasses that exist:

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

-- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

You can literally piggyback on Show's machinery for generic deriving? I don't understand the issue here. If the output is not easily-read by humans, then implement the instance yourself? Le 08/07/2021 à 22:01, Henning Thielemann a écrit :

On Thu, 8 Jul 2021, Hécate wrote:

...

...

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

* Extensive publicity of this typeclass in community (social media, etc) * Stock deriving (implemented by GHC & the CLC)

That works for Show, because Show is expected to display Haskell code. But how would you automatically derive human readable text from an arbitrary algebraic data type?

...

* First-class place in documentation (Documentation Task Force of the HF) * Coordinated effort with popular libraries to implement its adoption (CLC + stakeholders) * Maybe a code-modding script using retrie.

We will have to work as a community on that one but I am convinced that this is doable.

-- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

It may be worth noting that on a smaller, incremental scale, once `Render` is established, there would be incentives to fix some of the non-lawful `Show` instances, which would introduce transient breakage for the consumers of the affected packages.

GHC releases frequently fix situations where code that was previously accepted will be rejected, so it feels normal that we decide to fix unlawful Show instances while providing a more adapted solution for human-readable outputs. :) Le 08/07/2021 à 23:37, Viktor Dukhovni a écrit :

On Thu, Jul 08, 2021 at 11:07:36PM +0200, Hécate wrote:

...

You can literally piggyback on Show's machinery for generic deriving? I don't understand the issue here. If the output is not easily-read by humans, then implement the instance yourself? Indeed a `Render` (module bikeshedding the name) class can be derived in much the same way as `Show`, but might not be as friendly in many cases, because generically it would emit constructor and field names that might be omitted in a more friendly rendition of the structure.

So `Render` would warrant a specialised instance in more cases.

One might perhaps `render` a date in ISO 8601 format, skipping the constructor names.

If, for example, it was decided that a DNS Resource Record should `render` to its RFC Presentation form, then one might want to render a list of resource records (an RRSet) by just joining newline separated strings:

> putStrLn $ render $ [ { rname = "example.com." , rclass = IN , rdata = RData { T_A "192.0.2.1" } , { rname = "example.com." , rclass = IN , rdata = RData { T_A "127.0.0.1" } ] example.com. IN A 192.0.2.1 example.com. IN A 127.0.0.1 >

rather than as:

["example.com. IN A 192.0.2.1","example.com. IN A 127.0.0.1"]

taking advantage of the possibility of custom presentation of lists.

It may be worth noting that on a smaller, incremental scale, once `Render` is established, there would be incentives to fix some of the non-lawful `Show` instances, which would introduce transient breakage for the consumers of the affected packages.

-- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

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#usi... 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 mailto:lemming@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@haskell.org mailto:Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On Thu, Jul 08, 2021 at 10:48:28PM +0300, Oleg Grenrus wrote:

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.

This is NOT viable, not all escapes are valid to unescape after the fact in a print function. Which pieces of the `show` output are escaped unicode characters, and which are not depends on the original data type that got serialised to a given `String`. For example, in a `ByteString` the octet '\xFC' should display as '\252', while in a `String` or `Text` U+00FC should display as 'ü'. Thus, there is no correct unescape function for the string "M\\252ller", it could be "Müller", or not... -- Viktor.

On 08-07-21 19:04, Travis Cardwell via Libraries wrote:

This is the primary motivation of the TTC (Textual Type Classes) library: https://hackage.haskell.org/package/ttc.

It provides a Render type class that is analogous to Show and a Parse type class that is analogous to Read. No instances are declared so that users of the library can implement instances as required for each application, but default instances for core types are available.

Not related to the main point of the thread, but we really need a way to signal certain libraries as the "go to solution" for a problem without including them in "base". A note on the Show/Read class documentation saying that the best solution for "showing" human text is certain library would be great. -- -- Rubén -- pgp: 4EE9 28F7 932E F4AD

On Sun, Jul 11, 2021 at 03:11:02PM +0300, Oleg Grenrus wrote:

This is tricky design. Any instance in the composition which doesn't define showsPrecUnicode will ruin formatting of inner Strings. Maybe it's not as bad as in aeson* as most Show instances are derived. (But not Show1 etc.)

Yes, if a manually defined instance uses `show` on a substructure that contains strings, the strings will be rendered with unicode characters escaped. As you note, the ability to retain Unicode representations of nested structures would depend on either derived instances or tweaks to manual instances to also define the Unicode-preserving methods. This would not be perfect, but would avoid disruption, and so should have a much easier path to deployment. Over time the instances that fail to preserve Unicode strings can be refined. If tests in various packages are incrementally changed to use `showUnicode` to verify expected output, eventually we may be able to make `show` also Unicode-preserving, with much less disruption. This can provide a migration path over O(10yr) from the status quo to a Unicode-friendly `show`. -- Viktor.