Plan for file processing libs

[Bulat Ziganshin]

Hello libraries,

i think that ultimate structure for file-related libs should be the
following, in the dependence order:

* ByteString support
* UnicodeByteString support
* Stringable class that supports the common interface to String,
     UTF8ByteString, UTF16ByteString and so on
* FilePath operations implemented via Stringable class
* FileSystem operations (readdir, stat, copy, delete, mkdir...)
     implemented for Stringable arguments using FilePath module
* FD operations which supports manipulation of file contents via
     unix-style file descriptors (read/write/seek) where 'open'
     operation should support any Stringable parameter
* Streams-like layer which provides rich set of file manipulation
     operations in native Haskell way and use FD operations for its
     file support
* NewBinary-like layer which provides binary I/O and serialization on
     top of Streams

Neil, as one variant of placing FilePath module we may join filepath,
filesystem and FD levels into the one library, say named Files.
currently, we can include here:

* FilePath module
* copies of System.Directory, System.Directory.Internals,
     System.Posix.Internals modules which is now *unsupported* part of Base lib
* System.FD and System.MMapFile modules from my Streams lib

so, this lib will provide a rich set of file-related operations -
from parsing filenames to low-level access to file contents, allowing
to put more sophisticated I/O libs on top of it

the reason to put high-level I/O lib in separate package is that there
are plenty of different design choices possible (and exists). on the other
hand, all operations provided by such Files library are low-level ones,
there are no design decisions here


-- 
Best regards,
 Bulat                          mailto:Bulat.Ziganshin at gmail.com