Dear David Kraeutmann, thank you for your advice. Now I know that the best thing to do before I submit something to GHC Trac was nothing but actually to submit it :) https://ghc.haskell.org/trac/ghc/ticket/11529#ticket Dear David Feuer, thank you for your suggestion. I also think `ushow` is a good idea. Then we'd like to have a ghci flag, that switches the `show` in the REPL to `ushow` . Shall we continue the discussion to the ticket #11529, and could you please help me list up the cases where the change will break the assumptions of existing codes? Takayuki MURANUSHI RIKEN Advanced Institute for Computational Science http://nushio3.github.io/ http://www.geocities.jp/takascience/ 2016-02-03 11:05 GMT+09:00 David Feuer :

Unfortunately, I don't think there is any way to do exactly this without breaking the assumptions of a lot of existing code. But I suspect you can work around the problem in a few different ways, one of which strikes me as reasonable, if not quite perfectly accurate in all cases:

Write a function ushow that applies show to the given element, then digs through the resulting string converting escape sequences corresponding to valid Unicode codepoints into those codepoints.

On Tue, Feb 2, 2016 at 8:37 PM, Takayuki Muranushi wrote:

...

Show instance for non-ascii characters prints their character codes. This is sad for Haskell users that speaks language other than English.

...

'A' 'A' 'Ä' '\196' '漢' '\28450' print $ [(++"'s dad"), (++"'s mom")] <*> ["Simon", "John"] ["Simon's dad","John's dad","Simon's mom","John's mom"] print $ [(++"の父"), (++"の母")] <*> ["田中", "山田"] ["\30000\20013\12398\29238","\23665\30000\12398\29238","\30000\20013\12398\27597","\23665\30000\12398\27597"]

The function that needs improvement is showLitChar in GHC.Show, which currently prints any character larger than ASCII code 127 by its character code:

http://haddock.stackage.org/lts-5.1/base-4.8.2.0/src/GHC-Show.html

showLitChar :: Char -> ShowS showLitChar c s | c > '\DEL' = showChar '\\' (protectEsc isDec (shows (ord c)) s)

On the other hand, there is GHC.Unicode.isPrint, the predicate for printable Unicode characters, that is calling on a foreign function u_iswprint for the knowledge.

https://hackage.haskell.org/package/base-4.8.2.0/docs/src/GHC.Unicode.html#i...

I think one of the solution is to import and call u_iswprint from GHC.Show, too, but I don't know it's against any design choices.

Yesterday, I had a chance to teach Haskell (in Japanese,) and I had to use English in some of the most exciting examples, like the Applicative List example above. I would heartedly like to see GHC improve in these directions, so that we can make more happy learning materials on Haskell.

Let me ask your opinions on what is the best way to do this (or is better not to do this), before I submit something to GHC Trac.

Best,

-------------------------------- -- Takayuki MURANUSHI -- RIKEN Advanced Institute for Computational Science -- http://nushio3.github.io/ -- http://www.geocities.jp/takascience/ -------------------------------- _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

You could also use an approach similar to what 'lens' does and write a bit of Template Haskell to generate Unicode-aware Show instances. On 2/3/2016 10:11 PM, Atze van der Ploeg wrote:

I think we can all agree these characters should be shown. Maybe a GHC bug report is a good idea? On 02/03/2016 10:37 AM, Takayuki Muranushi wrote:

...

I think one of the solution is to import and call u_iswprint from GHC.Show, too, but I don't know it's against any design choices.

+1 for only escaping non-printable characters.

...

Yesterday, I had a chance to teach Haskell (in Japanese,) and I had to use English in some of the most exciting examples, like the Applicative List example above. I would heartedly like to see GHC improve in these directions, so that we can make more happy learning materials on Haskell.

As a workaround, perhaps you can avoid using print/show with core data structures. Using your applicative example:

...

mapM_ putStrLn $ [(++"の父"), (++"の母")] <*> ["田中", "山田"] 田中の父 山田の父 田中の母 山田の母

For other data structures, you can write your own Show instance:

data Name = Name String String

instance Show Name where show (Name family given) = family ++ given

...

print $ Person "山田" "太郎" 山田太郎

Travis _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Backwards compatibility is important, but not an absolute. I’d be curious if anyone can point to instances where software might _rely_ on the show instance for strings not displaying unicode characters? —Gershom On February 3, 2016 at 5:03:58 PM, David Feuer (david.feuer@gmail.com) wrote:

There's one open now. thomie commented ( https://ghc.haskell.org/trac/ghc/ticket/11529#comment:4 ) that it's possible to hook up your choice of showing function as the one GHCi should use to display values. This strikes me as the best available approach preserving backwards compatibility. Adding a GHCi flag for this might be reasonable.

On Wed, Feb 3, 2016 at 4:11 PM, Atze van der Ploeg wrote:

...

I think we can all agree these characters should be shown. Maybe a GHC bug report is a good idea? On 02/03/2016 10:37 AM, Takayuki Muranushi wrote:

...

I think one of the solution is to import and call u_iswprint from GHC.Show, too, but I don't know it's against any design choices.

+1 for only escaping non-printable characters.

...

Yesterday, I had a chance to teach Haskell (in Japanese,) and I had to use English in some of the most exciting examples, like the Applicative List example above. I would heartedly like to see GHC improve in these directions, so that we can make more happy learning materials on Haskell.

As a workaround, perhaps you can avoid using print/show with core data structures. Using your applicative example:

...

mapM_ putStrLn $ [(++"の父"), (++"の母")] <*> ["田中", "山田"] 田中の父 山田の父 田中の母 山田の母

For other data structures, you can write your own Show instance:

data Name = Name String String

instance Show Name where show (Name family given) = family ++ given

...

print $ Person "山田" "太郎" 山田太郎

Travis _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

If someone wants to view the byte values, why are they printing the string? Printing a string should display the string, not its underlying representation. To view the byte values, one can map over the string with fromEnum or something similar. On Wed, Feb 3, 2016 at 10:45 PM, Christopher Allen wrote:

Can be useful in debugging, such as when dealing with visually identical characters with different byte values. Having principally western characters be rendered is a bit chauvinistic. This use case could be addressed with a function that takes a list of byte ranges to be rendered literally, others being the byte version. That would at least dispose if one reason for opposing changing this.

On Wed, Feb 3, 2016 at 10:39 PM, Gershom B wrote:

...

Backwards compatibility is important, but not an absolute. I’d be curious if anyone can point to instances where software might _rely_ on the show instance for strings not displaying unicode characters?

—Gershom

On February 3, 2016 at 5:03:58 PM, David Feuer (david.feuer@gmail.com) wrote:

...

There's one open now. thomie commented ( https://ghc.haskell.org/trac/ghc/ticket/11529#comment:4 ) that it's possible to hook up your choice of showing function as the one GHCi should use to display values. This strikes me as the best available approach preserving backwards compatibility. Adding a GHCi flag for this might be reasonable.

On Wed, Feb 3, 2016 at 4:11 PM, Atze van der Ploeg wrote:

...

I think we can all agree these characters should be shown. Maybe a GHC bug report is a good idea? On 02/03/2016 10:37 AM, Takayuki Muranushi wrote:

...

I think one of the solution is to import and call u_iswprint from GHC.Show, too, but I don't know it's against any design choices.

+1 for only escaping non-printable characters.

...

Yesterday, I had a chance to teach Haskell (in Japanese,) and I had to use English in some of the most exciting examples, like the Applicative List example above. I would heartedly like to see GHC improve in these directions, so that we can make more happy learning materials on Haskell.

As a workaround, perhaps you can avoid using print/show with core data structures. Using your applicative example:

...

mapM_ putStrLn $ [(++"の父"), (++"の母")] <*> ["田中", "山田"] 田中の父 山田の父 田中の母 山田の母

For other data structures, you can write your own Show instance:

data Name = Name String String

instance Show Name where show (Name family given) = family ++ given

...

print $ Person "山田" "太郎" 山田太郎

Travis _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Chris Allen Currently working on http://haskellbook.com

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

What if (some) show instances where alternative representations are possible, were moved out of Prelude? A selection of modules with alternative show instances would be available from stand alone modules. To be imported as needed. For example, bytestring may be 'show'ed in different ways. Less convenient than now, backward incompatible yet simple enough.

This is by far the worst possible option. Incoherent instances lead to nightmarishly unpredictable behavior. On Thu, Feb 4, 2016 at 1:45 AM, Imants Cekusins wrote:

What if (some) show instances where alternative representations are possible, were moved out of Prelude?

A selection of modules with alternative show instances would be available from stand alone modules. To be imported as needed.

For example, bytestring may be 'show'ed in different ways.

Less convenient than now, backward incompatible yet simple enough.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

One of the most visible uses of Show is that it's how values are shown in GHCi. As mentioned earlier in this thread, if you're teaching in a non-ASCII language then the user experience is pretty poor. On the other hand, I see Show (like .ToString() in C# etc.) as a debugging tool: not for seriously robust serialisation but useful if you need to dump a value into a log message or email or similar. And in that situation it's very useful if it sticks to ASCII: non-ASCII content just isn't resilient enough to being passed around the network, truncated and generally mutilated on the way through. These are definitely two different concerns and they pull in opposite directions in this discussion. It's a matter of opinion which you think is more important. Me, I think the latter, but then I do a lot of logging and speak a language that fits into ASCII. YMMV! On 4 Feb 2016 07:38, "Imants Cekusins" wrote:

is the purpose of the show :

a) serialization to string? or b) text representation?

if a) then why is unexpected display - a concern? if b) then why is inconsistency - a concern?

if more than one way to display c is possible, then should we expect both a) and b) from Show? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On 04/02/16 09:47, Imants Cekusins wrote:

re: formatting GHCi output:

what if GHCi used another class (not Show) for formatting output?

what if it were possible to pass a cmd flag to ghci to specify formatting instance to use in this session?

It is possible: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/interactive-... -- http://mathr.co.uk

Hi, Am Mittwoch, den 03.02.2016, 23:39 -0500 schrieb Gershom B:

Backwards compatibility is important, but not an absolute. I’d be curious if anyone can point to instances where software might _rely_ on the show instance for strings not displaying unicode characters?

some people do use Show and Read as a quick-and-easy serialization/deserialization method, and some of them might assume that only ASCII characters are in use, so they maybe did not bother taking encodings in account when writing them out or in. There are many disencouraged practices mentioned in the above paragraph, but unfortunately, it’s our users that do disencouraged practices that most likely would not pay attention to breaking code changes in the standard libraries, are least likely to update their code and thus be hit the worst. It’s a pitty, and it should be added to the list of things to do better with the next larger language revision (if such a thing ever happens). Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

On 02/06/2016 12:58 AM, Michael Orlitzky wrote:

But for the terminal? Try Ctrl-Alt-F1 to drop out of X and into a Linux/BSD terminal, and runghc on a file containing,

main = mapM_ putStrLn $ [(++"の父"), (++"の母")] <*> ["田中", "山田"]

I get a bunch of grey question marks.

By default, Ctrl+Alt+F1 takes you to a "virtual console," which uses a framebuffer with very limited memory. Console fonts are limited to 256 glyphs, or 512 glyphs with fewer colors, which is too few glyphs for a proper CJK Unicode font. (**tangent below**) This issue applies to all Unicode software; it is not specific to Haskell. Cheers, Travis **tangent** It is possible to use Unicode outside of X with other software. For example, fbterm is a terminal emulator that selects fonts with fontconfig and renders them using freetype2, making the usual X fonts available for use. Here are some (Japanese) instructions for installation: Debian8 コンソールで日本語利用（fbterm） http://qiita.com/mtomoaki_96kg/items/e5a946fd38f7318d3758

Hi all, I wrote a small package for showing values in Unicode, to be used together with `-interactive-print`. I wish this is useful to you. https://github.com/nushio3/unicode-show#readme With print : $ ghci ...

["哈斯克尔7.6.1"] ["\21704\26031\20811\23572\&7.6.1"]

With uprint : $ ghci -interactive-print=Text.Show.Unicode.uprint Text.Show.Unicode ... Ok, modules loaded: Text.Show.Unicode.

("Хорошо!",["哈斯克尔7.6.1的力量","感じる"]) ("Хорошо!",["哈斯克尔7.6.1的力量","感じる"]) "改\n行" "改\n行"

There were several corner-cases, such as "\"" (a string with double quotation), "\23572\&7" (\& separates the Unicode literal from the digit character) and "3 :♡\& 5" (where :♡\& is a name of an infix value constructor.) If you find more corner cases, please let me know! Best, -------------------------------- -- Takayuki MURANUSHI -- RIKEN Advanced Institute for Computational Science -- http://nushio3.github.io/ -- http://www.geocities.jp/takascience/ -------------------------------- 2016-02-04 20:18 GMT+09:00 Chris Wong :

Have you considered using IHaskell instead?

https://github.com/gibiansky/IHaskell

It supports images and interactive widgets. It shouldn't be too hard to make it display Unicode text.

On Wed, Feb 3, 2016 at 12:37 PM, Takayuki Muranushi wrote:

...

Show instance for non-ascii characters prints their character codes. This is sad for Haskell users that speaks language other than English.

...

'A' 'A' 'Ä' '\196' '漢' '\28450' print $ [(++"'s dad"), (++"'s mom")] <*> ["Simon", "John"] ["Simon's dad","John's dad","Simon's mom","John's mom"] print $ [(++"の父"), (++"の母")] <*> ["田中", "山田"] ["\30000\20013\12398\29238","\23665\30000\12398\29238","\30000\20013\12398\27597","\23665\30000\12398\27597"]

The function that needs improvement is showLitChar in GHC.Show, which currently prints any character larger than ASCII code 127 by its character code:

http://haddock.stackage.org/lts-5.1/base-4.8.2.0/src/GHC-Show.html

showLitChar :: Char -> ShowS showLitChar c s | c > '\DEL' = showChar '\\' (protectEsc isDec (shows (ord c)) s)

On the other hand, there is GHC.Unicode.isPrint, the predicate for printable Unicode characters, that is calling on a foreign function u_iswprint for the knowledge.

https://hackage.haskell.org/package/base-4.8.2.0/docs/src/GHC.Unicode.html#i...

I think one of the solution is to import and call u_iswprint from GHC.Show, too, but I don't know it's against any design choices.

Yesterday, I had a chance to teach Haskell (in Japanese,) and I had to use English in some of the most exciting examples, like the Applicative List example above. I would heartedly like to see GHC improve in these directions, so that we can make more happy learning materials on Haskell.

Let me ask your opinions on what is the best way to do this (or is better not to do this), before I submit something to GHC Trac.

Best,

-------------------------------- -- Takayuki MURANUSHI -- RIKEN Advanced Institute for Computational Science -- http://nushio3.github.io/ -- http://www.geocities.jp/takascience/ -------------------------------- _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Chris Wong (https://lambda.xyz)

"I had not the vaguest idea what this meant and when I could not remember the words, my tutor threw the book at my head, which did not stimulate my intellect in any way." -- Bertrand Russell