I've been looking over some of the file-related modules such as System.Directory and System.Posix.{Directory,Files}, and I have some questions.
My 2p:
* Some languages have a means of building paths in a portable way. It would be nice if we had access a file separator (like "/" in unix and "\" in windows).
I've been against doing this in the past, because filename conventions differ so much between platforms (case sensitivity, length restrictions on components, syntax for drivenames, what is the meaning of consecutive pathname separators, etc.). However, there's clearly a need for some way to do simple pathname manipulations in a portable way. So my suggestion is to have something like: parentDirectory :: FilePath -> Mabye FilePath relativeToDirectory :: FilePath -> FilePath -> Maybe FilePath normaliseFilePath :: FilePath -> FilePath so you could say things like "my.conf" `relativeToDirectory` configDir It occurs to me that FilePath should be an abstract type. That would force the issue: we'd have to deal with all those existing cases which manipulate FilePaths and work out what abstractions we need. I don't like the idea of having a System.Directory.Native whose interface changes depending on the host platform. I think it's because platform-dependent APIs tend to lead to fine-grained #ifdefing in client code, and hence subtle portability problems. In libraries I try to stick to modules whose presence (only) depends on the platform, but there are definitely existing cases which violate this principle.
"path.separator" Path separator (for example, ":")
looks like a bad idea to me: application dependent.
"file.separator" File separator (for example, "/") "user.home" User home directory "user.name" User account name
// might come in useful: "os.arch" Operating system architecture "os.name" Operating system name "os.version" Operating system version
System.Info already provides these (except the version).
* Another item that would be useful in the System.Directory class would be some kind of config file path. On Debian, that would be "/etc", on some systems, it might tend to be more often "/usr/local/etc". (I'm not sure if there's a good way to abstract the difference between a user config file and a system config file. User config files tend to be in ~/ and start with a dot whereas system config files end up in /etc, and don't start with a dot.)
The location of config files is something you want to specify via the build system. eg. ./configure --prefix=/opt should cause configuration files to be placed under /opt instead of the default location (/usr/local?). Which means that if the config file location were provided via a Haskell library, that library would have to consult an environment variable or something. ( looking through the followups, it looks like Ketil already mentioned this point). This just doesn't look like the right abstraction to me. I think it's better to let the build system (or library infrastructure) provide this kind of information, perhaps by auto-generating a module. Cheers, Simon