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