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