Neil Mitchell wrote:
How about
class FilePathLike a where getRealFilePath :: a -> String
Then convert readFile etc. to take a FilePathLike, rather than a filepath?
Uhm, just a minute ago the argument was that we can't change the IO library... Anyway, my gut says, it dislikes 'class FilePathLike'. Gives us even less well defined semantics than a plain string.
Windows doesn't use UTF-16, NTFS does.
I was under the impression that NT's Unicode support was conceived when it meant UCS-2. So it uses UCS-2 and not UTF-16, which would mean that you could in principle encounter lone surrogate characters or something equally nonsensical.
FAT doesn't. And what about the Samba drive I have mounted under Windows?
Windows has two sets of file system related functions, one for legacy 8-bit character sets, one for Unicode. What happens if I call the Unicode API on a FAT system that doesn't support it? Does it do a half-assed version of the locale specific encoding that we deem impossible and wrong here? Ah, never mind, I get the strong feeling I really don't want to know all this. When even Windows 98 has been end-of-lifed we should rely on the Unicode API, if anything. Udo. -- "There are three ways to make money. You can inherit it. You can marry it. You can steal it." -- conventional wisdom in Italy