Hal Daume III writes:

For the last, see:

http://www.haskell.org/pipermail/haskell/2003-July/012314.html

and replies.

I forgot about this thread. I knew I'd been thinking about this for a few months, now I know why ;)

I still want *something* rather than nothing. Nice would even be:

makePath :: [FilePath] -> IO FilePath

And likewise, I think you'd want a way to parse a path into its components. About the drives in Windows, java has a function somewhere called "get roots" which on unix will give you "/" and on windows will give you "C:", "D:", etc. This makes sense to me. But about the case sensitivity, I have no idea. I agree that something would be better than nothing. peace, isaac

Am Donnerstag, 9. Oktober 2003, 10:24 schrieb Alastair Reid:

[...]

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.

Do we really need configuration files for this. Wouldn't the same be possible with a *.Native redirection module? In general, I would be very careful with following Java because, in my opinion, Java solutions are often not very nice (consider, e.g., Java's type system prior to J2SE 1.5).

A general mechanism for accessing configuration strings would be useful.

I would strongly favour mechanisms which give us type safety instead of mechanisms just using strings.

[...]

Wolfgang

Jan-Willem Maessen writes:

Alastair Reid writes:

...

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.

Actually, just delaying binding to System.Directory.Native would be enough (and I bet in such a system we'd want to delay binding to the prelude).

So how would this work? Some #ifdef sections in the implementations that bind System.Directory.Native, depending on which platform we're on? Would this be very hard? Are there more complex issues that I'm not seeing?

...

A general mechanism for accessing configuration strings would be useful.

Anyone taking up this task would get to choose a format. A chance to foist your aesthetics on the community! Surely that's irresistable to *somebody*.

I like the idea of type safety, but the configuration strings are probably still useful for some things. How might this look? - A constant CONFDIR (#ifdef'd into the implementations) telling where to find configuration files (a kind of bootstrapping) - A configuration file in CONFIGDIR with (var, val) tuples - The runtime system reads this file at startup? The virtue of this is that there is less work for the haskell implementors if there's just one #ifdef and everything else comes in as strings. Reading the file at runtime, however, seems a little strange since lots of the stuff we're talking about is actually known when you build the compiler. OTOH, maybe the work of having #ifdefs in the implementations isn't that hard? Obviously, there's platform-dependent configuration going on, but is there any going on that is eventually made available as constants or functions? Is there an implementation-neutral way to implement this? peace, isaac

Wolfgang Thaller writes:

As a long-time Mac user and victim of Apple's brainwashing, I hate config files, so I'm always sceptical about proposed schemes of config files. (Of course, I don't want to veto anything, I just want to dissuade people from inventing config file schemes "just in case we need them one day").

I can agree with that. I'm more-or-less trying to ask what each solution _would_ look like. I feel that the Library Infrastructure Project will be running into a lot of these platform dependent variables, and I want advice for a solution (and would be happy to see the solution itself too!) peace, isaac

For something like path separators, it seems fine to have Directory.Windows, Directory.Unix, and Directory.Mac, then have Directory.Native bind at compile time.

Note that it is (occasionally) useful to use Directory.Windows on a program running on a Unix box. One example would be a CVS-like application which has to translate filenames from one format to another.

So perhaps we could have

Platform.{Debian,FreeBSD,MacOSX,Windows98,Windows2000}. {configDirectory,fileSeparator,etc}

I find it harder to think why I would want to know where Windows machines store their configuration files. So I think there is value in having multiple versions of file-related modules available in each system but I'm much less convinced that having multiple configuration file locations available is useful. -- Alastair

Keith Wansbrough wrote:

...

...

Platform.{Debian,FreeBSD,MacOSX,Windows98,Windows2000}. {configDirectory,fileSeparator,etc}

I find it harder to think why I would want to know where Windows machines store their configuration files.

Furthermore, the location isn't fixed on Windows: it might be C:\WINDOWS\System (the most usual), or D:\WINDOWS\System (also possible), or <arbitrary-windows-path>\System (because the user can specify anything they like at install time).

So config-file location has to be per machine, not per OS.

Which suggests not putting it in the module heirarchy... Platform.UK.AC.CAM.CL.GLIA-NT.configDirectory, anyone? :)

I think it is a platform-dependent IO action: getConfigDirectory :: IO String This might simply be getConfigDirectory = return "/etc/" ... but on Windows, where the directories aren't fixed, and on Mac OS, where the directories are fixed but developers are told not to rely on that fact, we can use OS-specific functions for finding the correct location. (Bit is \Windows\System really for config files? I thought DLLs and drivers go there... but then I don't use Windows much.) Cheers, Wolfgang