[Haskell-cafe] File path programme

[ariep at xs4all.nl]

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?

Regards

Arie Peterson