[Haskell-cafe] Re: ANN: System.FilePath 0.9

[Brian Hulley]

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