> * 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