Plan for file processing libs

Duncan Coutts duncan.coutts at
Thu Nov 23 08:51:39 EST 2006

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.


More information about the Libraries mailing list