If there is no real difference the one that is better supported (with tutorials, examples etc.) will dominate the other. I don't see a reason to unify them. Let them duke it out :)
-deech On Wed, Jul 7, 2010 at 1:46 PM, Jonathan Daugherty <drcyg...@gmail.com> wrote: >> Anyway, the point remains, we need a single goto database library. >> >> Though the lack of response to this thread makes me think no one >> particularly thinks this is a problem. > > This is an interesting problem. For my part, I suspect the > proliferation of high-level database libraries is going to continue. > If you were to convince the present package maintainers to pitch in > and build a Grand Database Library, inevitably someone would come > along and build another one for whatever reason. Also, I don't think > the dust has settled on techniques for database access in Haskell in > any case, even for RDBMSs in particular. > > Since I couldn't agree more that duplication of effort is a sad thing, > I think a good place to start is for people to write database library > binding-only packages that get used by higher-level libraries like > HDBC and Takusen. Such libraries should include memory management > hooks specific to the sematics of the engine in question. There are a > couple of libraries for this on Hackage already, but they don't appear > to be used by any of the high-level database abstraction libraries. > > Otherwise I'd ask: what qualifies as a "go-to" library? Which users > should it satisfy? How accessible should it be? Most answers I can > think of lead me to believe enough people will be put off by it that > other libraries will pop up. :) > > -- > Jonathan Daugherty > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe