--- Simon Marlow
localPackageConfig is only for GHC 6.2: in 6.4, GHC and ghc-pkg will know where the local package conf lives, so Cabal won't need this knowledge built-in.
Good!
Last time this came up I asked for a concrete proposal, but no-one came forward with one. I'd do it myself, but I'm kind of busy right now. Would someone care to whip up a list of functions & signatures?
Ok. I will look at Python's OS.Path module, .Net's System.IO.Path class and the Utils module from Cabal and will summarize an API proposal together with some implementation.
I'm inclined to just stick something into the libraries even if it's not perfect. The filename handling issue is one of those things where trying to define a perfectly portable library is hard if not impossible, but having *something* is going to be useful to a lot of people, and as Krasimir says it'll have a lot of duplicated code.
Data.FilePath or System.Directory? I'm inclined towards the latter, since we clearly want functions that actually inspect the filesystem (findBinary, getExecutableFilePath) along with functions that just manipulate filenames, and it seems strange to split them up.
I prefer System.FilePath and System.Directory. Data.FilePath was my previous propsal but System is more suitable. In both Python and .Net there are separated namespaces for functions which are doing real IO operations and for FilePath parsing routines. Cheers, Krasimir _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com