Re: [Haskell] System.FilePath survey

On Mon, Feb 06, 2006 at 04:47:51PM +0200, Krasimir Angelov wrote:

2006/2/6, David Roundy :

...

Actually couldn't they all be made polymorphic?

getDirectoryContents :: FilePath p => IO p

class FilePath p where fromADT :: ADT -> p toADT :: p -> ADT

Would you mean that we should have two instances:

instance FilePath String where .... instance FilePath ADT where ....

It will work but I think that it is unnecessary complication. I prefer to use type classes only when they are really necessary i.e. when I have more than 2-3 instances or when I expect to have a lot of generic code that should work on both types.

The advantage would be that one could continue to use code that doesn't use the ADT for file paths, which would be convenient. And you'd need the conversion routines anyways, in order to display filepaths. True, it's just a convenience issue, but being able to write writeFile "output" contents would seem to me to be worth the complexity of having a class. In fact, I would think that all filepath-related code would work with either type. Also, this would allow users to define FastPackedStrings or whatever else to be in class FilePath, which is certainly something I've wanted to do with darcs, just to save the memory associated with all those Strings without the cost of converting to a String and then back to a CString (which the IO library must do internally) on every file operation.

I think that if we should switch from plain String to ADT then this should be made for a new i/o library (the Handle(s) replacement) which will change the thing a lot in any way. For the current library I think that the plain String is more reasonable. If the general consensus is that ADT is the way to go then I think some effort on a new efficient IO library be forced. It should have:

- FilePath ADT - Packed string - Fast I/O with unicode support

I know some pieces already exists but they need integration and polishing.

Indeed, it would be great to have a shiny new IO library, but even then I'd lean towards a FilePath class just for convenience. It'd be a royal pain for quickly written programs to have to always use (toADT "filename") when doing file IO with string literals. -- David Roundy http://www.darcs.net