[Takusen] Takusen package split and source re-org

Alistair Bayley alistair at abayley.org
Thu Jun 23 19:04:34 BST 2011

Hello Oleg,

>> Regarding (1): people have said that it's wrong for Takusen to have a
>> setup that changes the API depending on what you have installed, and
>> I'm inclined to agree.
> That is true, yet there is a reason for that: different back-end do
> have different ways of connecting to the database -- different API for
> connecting. There are many other subtle differences between
> databases. Certainly we may gloss over them; after all, all relational
> DBMS support a fair share of common SQL. One can do a lot using only
> that common functionality. Yet, if one deals with large databases or
> requires fast answers to queries, one has to become familiar with
> idiosyncrasies of a particular DBMS. The ability to use
> database-specific functions may be crucial at some times. If we don't
> provide it, the whole Takusen package becomes useless then. It is
> indeed a challenge how to unify different back-ends and yet preserve
> their differences for the cases where they matter.

Yes... the objection was more that whole modules were present (or not)
depending on which cabal flags you pass, which in turn depends on
which backends you have. Instead of cabal flags, we'd have separate
packages for the modules. I'm not planning to change the API within
any modules. Does that seem better?

> The new Repo structure indeed looks much nicer than before. I only
> have the comment on test/Test/, which contains general unit testing
> framework. It could well be a separate Hackage package, or even part
> of Haskell Platform. I would have put
>        Test/MiniUnit.hs
>        Test/MiniUnitTest.hs
> under core/src.



More information about the Takusen mailing list