[Takusen] [Haskell-cafe] ANNOUNCE: Takusen 0.8.6

Sun Aug 1 17:58:14 EDT 2010

Using the generous resources of community.haskell.org I've created a mailing
list for takusen discussions.  I encourage interested parties to join that
list and maybe move the takusen design discussion there:
  http://projects.haskell.org/cgi-bin/mailman/listinfo/takusen

I've added the list in the CC.

I've also created a trac instance for wiki/bug tracking:
  http://trac.haskell.org/takusen/report

My comments are below.

On Sun, Aug 1, 2010 at 12:55 PM, Alistair Bayley <alistair at abayley.org>wrote:

> 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.
>

More tutorials is a great idea.  Perhaps I can write a few simple 'how to
get started' examples and post them on my blog.  Although, the wiki is a
nice place too.  Any preference?  If I post it on my blog it might be easier
to control the formatting and voice, but if it's on the wiki other can
update it and it's in a central location.

>
>
> >  * 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?
>

This same issues comes up fairly often on the darcs-users mailing list.  My
understanding of the way things are handled there, is that if there is ever
a good reason to drop support for a version of GHC then the person who wants
to drop support is supposed to look and see what is in Debian stable.  If
debian stable is still covered after the proposed changes then they are
accepted automatically.  If Debian stable would not be covered, then there
is a discussion to reach consensus.

The reasons it works are: a) support is dropped lazily when there is a real
demand to do so, instead of artificially; b) letting people discuss it
case-by-case allows the decision to be made with full context.

>
> 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.
>

I think that iteratees are a wonderful concept and I like them, but...I'm
not terribly fond of the iteratee package.  I find that with it's full
generality that it is somewhat difficult to program with.  I've actually
found it easier to 'roll your own' when I need iteratees.  My preference
would be to switch to some later iteration of the iteratee design.  I
believe John Lato is currently working on a new API.

>
> 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.
>

I haven't looked at the regions package either, but it certainly sounds like
a good idea to switch to it.

>
> 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.
>

Refactoring to use more libraries is a good long term goal and once it's
done, it may make other development easier/quicker and more accessible to
people who are not core takusen contributors.  I agree that it's not a high
priority for me though.  The takusen code that uses those concepts is direct
enough that the embedded implementations are fine with me, for now.

>  - splitting Takusen into multiple packages: a core interface, and
> then separate packages for each backend.
>

In my opinion, this should be the highest priority refactor.  I believe it
brings the most benefit to takusen and to other competing database
libraries.  I don't think that each database library on hackage needs to
reimpement the FFI bits for talking to database engines.  Some will do it
from scratch regardless, but I bet most database libraries would be happy to
reuse the lowest level bits.

>  - better docs, as you've requested.
>

I hope to get started on this one.

>  - 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
>

Refactoring the backends so that they can be added to the above lists as
hackage packages would be very nice as well.

>
> 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.
>

We should note these suggestions in the bugtracker so we don't lose sight of
them:
  http://trac.haskell.org/takusen/report

Thanks,
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.haskell.org/pipermail/takusen/attachments/20100801/c46d2787/attachment.htm 