[Haskell-cafe] File path programme

[Simon Marlow]

[ moving to libraries at 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