-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This type of interface is fine as far as it goes, but there is only ever a loose coupling between the database and application.
The HaskellDB work implemented a relational calculus that ensured that all queries were checked at compile time for validity against a particular database. The problem with HaskellDB is that it defines a join operator that generates new types. Tom On Wed, 13 Aug 2003 02:02 am, Tom Pledger wrote: > Thomas L. Bevan writes: > | Does anyone know if there is work being done on a standard Haskell > | database interface. > > I suspect that there isn't. The pattern seems to be that someone gets > an interface working well enough for some purposes, and perhaps shares > it, but is too modest and/or busy to put it forward as a standard. > > For a row extraction mechanism, I'd vote for passing an extraction > function (or IO action) to the main query function, like Tim Docker > described last month. > > http://haskell.cs.yale.edu/pipermail/haskell-cafe/2003-July/004684.html > > This is a pretty good way to stop those nasty vague SQL row types at > the Haskell border and turn them into something respectable. Perhaps > it would even be worth constraining the extracted type to be in > DeepSeq > > doquery :: (DeepSeq v) => > Process -> String -> IO v -> IO [v] > > so that the interface clearly may confine its attention to one row at > a time per cursor. > > - Tom > > _______________________________________________ > Haskell-Cafe mailing list > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/haskell-cafe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Oj51Yha8TWXIQwoRAq0EAKCdfxWtB+D6cmZyOr7udXTXZtEgqQCgqIJM rvLjcYXJouR0Q59XkyC4/L4= =7F1i -----END PGP SIGNATURE----- _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
