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@gmail.com