Neil Mitchell wrote:
And if someone wants to define a "new" and "better" FilePath type, I would prefer something more abstract, such as a list of Path components, with functions to serialize it as a String and to parse it from a String.
A list of path components is just not enough, I'm afraid. What about extensions? What about drives? If you want an abstract type it will probably need to be entirely abstract, rather than with some exposed structure.
Why not just delete Unix and Windows from the equation altogether, and define a simple Haskell file system with something like: newtype Path a = Path [a] newtype Filename a = Filename a data Origin a -- some abstract type deriving Eq -- this would be nice if it is possible to implement data IString a => FileSpecifier a = FileSpecifier !(Origin a) !(Path a) !(Filename a) instance IString ByteString.Char8 ... instance IString String ... Origins could be created by a factory appropriate to the underlying operating system (they would represent drives or volumes or mount points) - in any case a drive can't be mentioned in a program or the program wouldn't be portable! Athough even with a nice rational reconstruction the monstrously unfortunate fact remains that Windows is case insensitive (how impossibly moronic!!!) and Unix isn't so it is not possible to write code that will work the same for both OS's if one is required to use filenames that will look the same in other OS apps (ie the trick of encoding the complete Unicode char set in terms of legal filename chars is probably not acceptable). Anyway this is probably straying too far from what you are trying to do at the moment. Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com