[Haskell-cafe] File path programme

ariep at xs4all.nl ariep at xs4all.nl
Wed Jan 26 13:11:01 EST 2005

On 26 January 2005 16:53, Simon Marlow wrote:

> On 26 January 2005 15:38, Keean Schupke wrote:
>> Not at all. You just include some nice operation in the class:
>> emptyPath :: Path p => p
>> appendPath :: Path p => p -> String -> p
>> etc...
>> So it is an abstract datatype and class. The user never needs to touch
>> the concrete type, even though they use it... The types remain
>> polymophic.
> The types can't remain completely polymorphic - at some point you have
> to say what type you want.  Because an ambiguous Path constraint cannot
> be resolved, the program will have to mention either Win32Path or
> PosixPath, at which point it becomes non-portable without conditinoal
> compilation.

Can't the actual instance be determined by some appropriate IO function?
For example: getHomeDirectory, getTempDirectory, getCurrentDirectory :: IO
Win32Path under windows; getHomeDirectory, getTempDirectory,
getCurrentDirectory :: IO PosixPath in a posix system. In this way, many
programs can be written in terms of polymorphic functions (such as
appendPath :: (Path p) => p -> String -> p) combined with e.g.
getHomeDirectory and be fully portable.

Someone may want to be able to store and retrieve paths, so we would need
platform-specific (or actually instance-specific) functions parsePath and
showPath. These functions should not be part of the class Path, because
their types must be monomorphic, like that of getHomeDirectory.
If it must be possible to work with non-native paths as well, we could
also make parsePath and showPath class members and have separate
parseNativePath and showNativePath with monomorphic type signatures.

Programs that need more than these common getHomeDirectory-like functions
are bound to be non-portable anyway, right?

Might it be possible or useful to make Uri an instance of Path as well?


Arie Peterson

More information about the Libraries mailing list