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