[Haskell] System.FilePath survey

[David Roundy]

On Mon, Feb 06, 2006 at 04:47:51PM +0200, Krasimir Angelov wrote:
> 2006/2/6, David Roundy <droundy at abridgegame.org>:
> > 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