[Haskell-cafe] ANNOUNCE: Takusen 0.8.6

[Alistair Bayley]

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