At the risk of seeming a bit defensive, I'll respond to some of these points...
Despite this, it seems to have a couple faults: * Few tutorials, aside from the Haddocks in Database.Enumerator
True. I put a bit of effort in to writing the docs in Database.Enumerator as a sort of tutorial, but it doesn't work as well as a properly written tutorial. Perhaps this would be better placed on the wiki, but it's quite a bit of work, assuming you would prefer something more than a simple cut-n-paste from the generated docs.
* Very crufty old code in some spots (I see lots of references to GHC 6.6 and the 'extensible exceptions' changes in the cabal file among other places, which I believe we're all well beyond now. There also seems to be random tidbits that could be removed in favor of a library/removed because they're not necessary.) This should IMO all be removed under the argument "Get a more recent GHC" although people may disagree here.
Maybe... We've put some effort into supporting older versions of ghc, mainly because quite a few distributions have quite long update cycles. If you're stuck in an environment (some unis, some employers?) where you are only allowed tools from the last stable distribution, you may well be many releases behind current ghc. If everyone agrees that 6.8 should be the oldest ghc we should test and support, then that does make things a little simpler. Are there any distros still shipping with ghc-6.6? BTW, I thought extensible-exceptions first shipped with 6.10. I don't think everyone is off 6.8 yet, so we'd want to keep that cabal switch in for a little longer if we intend to support 6.8.
* It would be nice if we could make it depend on nicer libraries instead of rolling its own stuff - for example, we have Lato's excellent iteratee package, and Bas van Dijk has written a (IMO woefully underappreciated!) 'regions' package with encapsulate the lightweight monadic regions idea Oleg proposed. Of course, due to design, neither of these may work properly for Takusen's case, and if they did they would very likely facilitate API changes, but it's something I've been thinking about in the name of making the library smaller and more lightweight.
iteratee and regions were both released well after Takusen was written. I think iteratee is just the same idea generalised to other types (Binary, ByteStrings, IO, etc). Perhaps it would help to use it and standardise the interface, but I haven't looked into it at all. It looks like it might be a considerable amount of work. Using regions might be more feasible (i.e. easier), but again I haven't considered it. Takusen's implementation also pre-dates regions considerably, and it works well for us as is. The actual implementation is very little code. That is, in both cases I don't see a big benefit from switching over to these libraries, considering the amount of work I think it would take (esp for iteratee). There are plenty of other things on the to-do list which I think should take higher priority e.g. - splitting Takusen into multiple packages: a core interface, and then separate packages for each backend. - better docs, as you've requested. - support for blobs/clobs As Gregory just pointed out, using other libs adds further dependencies to Takusen. One of our earlier goals was to make it easy to install, which in the days before cabal meant fewer dependencies on external libs. cabal now mitigates that concern considerably, so perhaps we should relax more now when it comes to using external libs. Here is the list of things that I can think of right now which are currently internalised in Takusen, but which are also implementated in hackage libs: - extensible exceptions - EMonadIO - regions - iteratee I'm not saying the way it is now is right or best, but it got there through various historical decisions, which were made with the best information available at the time, and in environments that differ from the current. Alistair