6.12.1rc1: non-Latin filenames in GHCi
I've noticed that when I load in GHCi a file that has a non-latin name, although it gets loaded, its name appears garbled in the message after the loading:
Prelude> :load πρόχειρον.hs [1 of 1] Compiling Main ( ÏÏÎ ¿ÌÏειÏον.hs, interpreted ) Ok, modules loaded: Main. *Main>
Is this expected, or something is wrong with my setup? It's a rather insignificant issue, but I thought to ask about it. I'm using GHC 6.12.1rc1 on Mac OS X 10.6.1. Thanks very much, Christos Chryssochoidis
christosc:
I've noticed that when I load in GHCi a file that has a non-latin name, although it gets loaded, its name appears garbled in the message after the loading:
Prelude> :load πρόχειρον.hs [1 of 1] Compiling Main ( ÏÏοÌÏειÏον.hs, interpreted ) Ok, modules loaded: Main. *Main>
Is this expected, or something is wrong with my setup? It's a rather insignificant issue, but I thought to ask about it. I'm using GHC 6.12.1rc1 on Mac OS X 10.6.1.
Perhaps you're seeing the GHC support for locales in 6.12. http://ghcmutterings.wordpress.com/2009/09/30/heads-up-what-you-need-to-know...
Thanks Don for your reply. I may have overlooked something in the blog post you gave, but my understanding is that it talks about the user's input/output to and from GHCi and the file system. The user IO with non-Latin chars seems to work fine in GHC 6.12.1; e.g.:
*Main> putStrLn "πρόχειρον.hs" πρόχειρον.hs
*Main> getLine >>= putStrLn πρόχειρον.hs πρόχειρον.hs *Main>
It's only when GHCi attempts to print a diagnostic message containing a filename with non-Latin chars that the garbling occurs:
*Main> :load πρόχειρον.hs [1 of 1] Compiling Main ( ÏÏÎ ¿ÌÏειÏον.hs, interpreted )
ÏÏοÌÏειÏον.hs:1:23: Not in scope: type constructor or class `Boo' Failed, modules loaded: none. Prelude>
It would be nice if the error messages at least showed correctly the filename. Maybe this has something to do with Haskeline? Anyway thanks again, Christos On 18 Οκτ 2009, at 6:11 μ.μ., Don Stewart wrote:
christosc:
I've noticed that when I load in GHCi a file that has a non-latin name, although it gets loaded, its name appears garbled in the message after the loading:
Prelude> :load πρόχειρον.hs [1 of 1] Compiling Main ( ÏÏÎ ¿ÌÏειÏον.hs, interpreted ) Ok, modules loaded: Main. *Main>
Is this expected, or something is wrong with my setup? It's a rather insignificant issue, but I thought to ask about it. I'm using GHC 6.12.1rc1 on Mac OS X 10.6.1.
Perhaps you're seeing the GHC support for locales in 6.12.
http://ghcmutterings.wordpress.com/2009/09/30/heads-up-what-you-need-to-know... _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On 18/10/2009 20:15, Chryssochoidis Christos wrote:
Thanks Don for your reply. I may have overlooked something in the blog post you gave, but my understanding is that it talks about the user's input/output to and from GHCi and the file system. The user IO with non-Latin chars seems to work fine in GHC 6.12.1; e.g.:
*Main> putStrLn "πρόχειρον.hs" πρόχειρον.hs
*Main> getLine >>= putStrLn πρόχειρον.hs πρόχειρον.hs *Main>
It's only when GHCi attempts to print a diagnostic message containing a filename with non-Latin chars that the garbling occurs:
*Main> :load πρόχειρον.hs [1 of 1] Compiling Main ( ÏÏοÌÏειÏον.hs, interpreted )
ÏÏοÌÏειÏον.hs:1:23: Not in scope: type constructor or class `Boo' Failed, modules loaded: none. Prelude>
It would be nice if the error messages at least showed correctly the filename.
Maybe this has something to do with Haskeline?
It's not to do with Haskeline. The real underlying problem is that our filesystem APIs on Unix interpret FilePath as [Word8] without doing any encoding/decoding; they just strip off all but the low 8 bits of each Char. This is a long-standing problem, and won't be solved properly until we switch to an abstract FilePath type, but that's a big change that will break lots of code. Lots more good discussion here: http://hackage.haskell.org/trac/ghc/ticket/3456 If there were a filePathToString function we could use it in GHC to fix the above glitch. Cheers, Simon
On 20 Οκτ 2009, at 3:08 μ.μ., Simon Marlow wrote:
It's not to do with Haskeline. The real underlying problem is that our filesystem APIs on Unix interpret FilePath as [Word8] without doing any encoding/decoding; they just strip off all but the low 8 bits of each Char. This is a long-standing problem, and won't be solved properly until we switch to an abstract FilePath type, but that's a big change that will break lots of code.
Lots more good discussion here:
http://hackage.haskell.org/trac/ghc/ticket/3456
If there were a filePathToString function we could use it in GHC to fix the above glitch.
Cheers, Simon
Understood. Thank you very much for the pointer and your response. -- C. Chryssochoidis
participants (3)
-
Chryssochoidis Christos -
Don Stewart -
Simon Marlow