[ moving to libraries@haskell.org ] On 26 January 2005 12:22, Malcolm Wallace wrote:
Could we just punt this library for this release. After all we can add libraries in a later point release (eg 6.4.1) you just can't change existing APIs.
FWIW, I agree with Duncan, Ben, and Peter, that the new System.FilePath interface is broken, and the implementation more so. It would be better to redesign FilePaths as an algebraic datatype.
Ok, I'll go with the concensus. System.FilePath in its current state will be removed from the base package. Isaac or Krasimir: can you make the required changes to Cabal? (the code is already duplicated in Distribution.Compat.FilePath, just remove the import for GHC). So let's aim for 6.6 to do it right, and design an abstract type for path names. We have to think about the migration path: Haskell 98 programs must continue to work, so at least IO.FilePath must still be a String, and IO.openFile must still take a String. We can therefore: (a) make System.IO.FilePath be the new type, which is different from, and incompatible with, IO.FilePath. Similarly for System.IO.openFile, System.Directory.removeFile, and so on. (b) or just define a new type, and force you to insert read/show to convert where necessary, eg. before calling openFile. (a) is kind of the right thing, but (b) is a lot less painful in the short term. Since we'll be migrating to a new IO library at some point, (b) is probably fine (the new IO library can use the new FilePaths exclusively), but we'll need to migrate System.Directory too. Would someone like to take up the reigns on the design for the new library? Cheers, Simon