My solution would be to have the API "random-access" based, and then have a type that provided the current stream-based interface (which I would use for your example):
Operating systems, IO libraries, etc. like sequential access because they can play all sorts of tricks with reading ahead, buffering, etc. to overcome the latency of the physical disk and the overhead of performing a system call. This makes a huge difference to performance. It works because most access is sequential. Two consequences: 1) You would probably want the implementation of files in the Haskell libraries to perform buffering exactly the same whether you provide a sequential access API (as at present) or a random access API (as proposed). 2) If you were to build a sequential API on top of a random access API, you would want to take care that buffering still works effectively. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/