...

...

...

...

"Judah" == Judah Jacobson writes:

Judah> On Wed, Aug 19, 2009 at 10:31 AM, Iain Barnett wrote: >> Quick question: I've tested this in a couple of different >> terminals (roxterm and xterm), so I'm fairly sure it's GHC >> that's the problem. Have I missed a setting? GHCi, version >> 6.10.4 Prelude> putStrLn "£" >> � Hugs98 200609-3 Hugs> putStrLn "£" >> £ >> ghc-6.10.4 and earlier don't automatically encode/decode Unicode Judah> characters. So on terminals which don't use the latin-1 Judah> encoding, you need to do the conversion explicitly with a Judah> separate package such as utf8-string, iconv or text-icu. I don't understand where latin-1 comes into this. String is supposed to be a list of Unicode characters. -- Colin Adams Preston Lancashire

...

...

...

...

"Bulat" == Bulat Ziganshin writes:

Bulat> Hello Colin, Bulat> Thursday, August 20, 2009, 10:13:28 AM, you wrote:

I don't understand where latin-1 comes into this. String is supposed >> to be a list of Unicode characters.

Bulat> but ghc 6.10 i/o used String as list of bytes But how do you get Latin-1 bytes from a Unicode string? This would need a transcoding process. -- Colin Adams Preston Lancashire

...

...

...

...

"Stuart" == Stuart Cook writes:

Stuart> On Thu, Aug 20, 2009 at 4:28 PM, Colin Paul Stuart> Adams wrote: >> But how do you get Latin-1 bytes from a Unicode string? This >> would need a transcoding process. Stuart> The first 256 code-points of Unicode coincide with Stuart> Latin-1. Therefore, if you truncate Unicode characters Stuart> down to 8 bits you'll effectively end up with Latin-1 text Stuart> (except that any code points above U+00FF will give Stuart> strange results). Stuart> If your terminal then interprets these bytes as UTF-8 (or Stuart> anything else, really), the result will be gibberish or Stuart> worse. Yes, but surely this will work both ways. The same bytes on input should come back on output, shouldn't they? -- Colin Adams Preston Lancashire

On Thu, Aug 20, 2009 at 5:12 PM, Colin Paul Adams wrote:

Yes, but surely this will work both ways. The same bytes on input should come back on output, shouldn't they?

I would have thought so, but apparently this isn't actually what happens. GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> map Data.Char.ord "饁" [39233] <== 0x9941 Prelude> putStrLn "饁" A <== 0x41 It seems that GHCi is clever enough to decode UTF-8 input, which only serves to confuse System.IO even more. Stuart

2009/8/20 Ketil Malde

Stuart Cook writes:

...

GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> map Data.Char.ord "饁" [39233] <== 0x9941 Prelude> putStrLn "饁" A <== 0x41

...

It seems that GHCi is clever enough to decode UTF-8 input, which only serves to confuse System.IO even more.

I get:

GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> map Data.Char.ord "饁" [39233]

and

Prelude> map Data.Char.ord "£" [163]

but also:

% ghci -e 'map Data.Char.ord "饁"' <interactive>:1:21: lexical error in string/character literal at character '\129'

but again:

% ghci -e 'map Data.Char.ord "£"' [194,163]

So GHCi used interactively translates input from the terminal's UTF-8, but outputs truncates output to eight bits. Executing a string with -e, it appears to read byte for byte (which I think was the original behavior at some point).

-k --

I get the same behaviour here. If you want to try Latin 1 (ISO-8859-1) then you can use a utility called Luit (maybe only Linux?) luit -encoding ISO-8859-1 ghci £ becomes £, but gives the same byte output as above. Iain

Got this back from the bug tracker 6.12.1 will have Unicode support in the IO library which mostly fixes this problem. The rest is fixed by #3398. Iain