behaviour change in getDirectoryContents in GHC 7.2?

Max Bolingbroke batterseapower at
Wed Nov 2 19:55:16 CET 2011

On 2 November 2011 17:15, John Millikin <jmillikin at> wrote:
> What package does this patch -- "unix", "directory", something else?

The "base" package. The problem lay in the implementation of
GHC.IO.Encoding.fileSystemEncoding on non-Windows OSes.

> Maybe I'm misunderstanding, but it sounds like you're still trying to
> treat posix file paths as text. There should not be any iconv or
> locales or anything involved in looking up a posix file path.

The thing is that on every non-Unix OS paths *can* be interpreted as
text, and people expect them to be. In fact, even on Unix most
programs/frameworks interpret them as text - e.g. IIRC QT's QString
class is used for filenames in that framework, and if you view
filenames in an end-user app like Nautilus it obviously decodes them
in the current locale for presentation.

Paths as text is just what people expect, and is grandfathered into
the Haskell libraries itself as "type FilePath = String". PEP-383
behaviour is (I think) a good way to satisfy this expectation while
still not sacrificing the ability to deal with files that have names
encoded in some way other than the locale encoding.

(Perhaps if Haskell had an abstract FilePath data type rather than
FilePath = String we could do something different. But it's not clear
if we could, without also having ugliness like getArgs :: IO [Byte])


More information about the Glasgow-haskell-users mailing list