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
signature.asc
Description: Digital signature
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
