[Haskell-cafe] Re: Streams: the extensible I/O library

[Simon Marlow]

Bulat Ziganshin wrote:

> I have developed a new I/O library that IMHO is so sharp that it can
> eventually replace the current I/O facilities based on using Handles.
> The main advantage of the new library is its strong modular design
> using typeclasses.

I've taken a brief look, and I must say it's nice (but you knew that 
anyway :-)).

My initial thoughts:

I would prefer to see more type structure, rather than putting 
everything in the Stream class.  You have classes ByteStream, 
BlockStream etc, but these are just renamings of the Stream class. There 
are many compositions that are illegal, but we don't find out until 
runtime; it would make a lot more sense to me to expose this structure 
in the type system.

My view is that the most basic level of stream is a byte stream, 
supporting only two operations: read an array of bytes and write an 
array of bytes, i.e. vGetBuf/vPutBuf.  This makes implementing a stream, 
or transformer, much easier and shorter.  Also I'd like to see separate 
input/output streams for even more type safety, and I believe 
simplicity, but this is less important than separating byte streams from 
text streams.  I believe certain other operations would benefit from 
being moved into separate classes: eg. vSeek into a Seekable class, 
vSetBuffering into a Buffered class, and so on.  This will improve 
performance too - your Stream class has dictionaries with 20+ elements.

I see that buffering works on vPutChar/vGetChar, and yet you seem to be 
buffering bytes - which is it?  Are you supposed to buffer before or 
after doing character encoding?  It seems before, because otherwise 
buffering will strip out all but the low 8 bits of each character. 
Using a more explicit type structure would help a lot here. 
Incedentally, I'm suprised that you can use list-based character 
encoding/decoding and still get good performance, I expected to need to 
do encoding directly between buffers.

Still, as I said, I think the general approach is excellent, and is 
definitely heading in the right direction.

Oh, and some of the code is GPL'd, which is a problem for incorporation 
in standard libraries.  This is just something to bear in mind if the 
aim is for this to be a candidate for a/the standard IO library.

Cheers,
	Simon