On Thu, 2006-11-23 at 13:23 +0300, Bulat Ziganshin wrote:
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
If you're talking about standardising some kind of Binary module I'd much rather see one based on lazy byte strings since this is pure. There is no need to tie binary serialisation to IO, file handles, or your streams proposal. I know some people are working on such an implementation. I think it will be possibly to make a nice serialisation api that is both pure and high performance. Actually, similarly, I don't think there is any need to tie a pure data structure modules like Data.ByteString (or the unicode variant Data.PackedString) to an IO package. Duncan