[Haskell-cafe] Re: ANN: System.FilePath 0.9
brianh at metamilk.com
Sat Jul 22 17:20:36 EDT 2006
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
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)
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
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
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.
More information about the Haskell-Cafe