-----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 Haskell-Cafe@haskell.org 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-----