Keean Schupke writes:
What about Peter Simons' BlockIO library?
I think BlockIO solves a different problem than the other proposals do. BlockIO doesn't really abstract different types of input sources, it does the opposite: it restricts I/O handlers to operate on raw memory buffers. A 'Handler' in BlockIO is a function with, approximately, this type: (Ptr Word8, Int) -> StateT st IO () Every time new input is available, this stateful computation is called by the main loop to process the data -- and this generic main loop can read from all kinds of input sources then. So instead of making a 'Handle' more abstract, BlockIO basically says: Handles don't exist, all we know are blocks of input data. A feature like 'gzip'ing a stream of data, for example, would be implemented as a monadic transformer for computations of the type given above. It wouldn't know anything about I/O either, it would operate on raw memory like the rest of the handlers does. The most obvious advantage of this design is speed. Personally, I also think it is "more functional" to pass a handler function for data obtained from the outside world instead of passing an abstract entity which can be "read from" (with all kinds of nasty error conditions). This design, however, is obviously meant for data streams: the concept of seeking simply doesn't exist. So although you can run a BlockIO handler from any conceivable input source, you cannot fit any conceivable input/output model into BlockIO. Peter