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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
