* Some languages have a means of building paths in a portable way.
The last discussion suggested that we might tackle this using the hierarchial module structure. That is, there would be System.Directory.Unix, System.Directory.Windows, System.Directory.Mac, etc. and then System.Directory.Native would be a redirection module that points to the appropriate module for that system. The Java approach you describe uses configuration files instead of modules. In favour of the module-based approach, there is stronger typechecking, greater flexibility (do we need this?) and the ability to manipulate filenames from multiple platforms at once (useful if you need to convert filenames from one platform to another). In favour of the configuration file approach, there's the potential for shipping portable bytecode files from one platform to another and it can probably be tweaked to support multiple platforms at once by providing a 'Configuration' abstract data type. I think that if we had a configuration file, we would want to treat them as runtime constants so that operations which depend on configuration constants don't need to be in the IO monad. And if we wanted a more general configuration file mechanism, we would do well to provide hooks so that embedded systems written in Haskell don't find themselves needing a filesystem just so that they have somewhere to read the configuration file from. (This is only really relevant if configuration files are used to configure more than just System.Directory since most programs that manipulate filenames tend to need a filesystem anyway.)
These last few points are rather related in that they are both dependent on particular operating systems, and a means of abstracting away system-specific details in order to write more portable code. Are any of these good ideas?
I think so, yes. A good library of filename manipulating functions would be useful. Following Java's lead and using configuration files to localize a system would potentially allow us to ship portable bytecode files around from one platform to another. A general mechanism for accessing configuration strings would be useful. -- Alastair Reid www.haskell-consulting.com