Database interface

[Tom Pledger]

Tim Docker writes:
 :
 | The list being folded over
 | is implied by the DB query, is accessible through the IO monad.
 | Hence a parameter is not required. It would really be:
 | 
 | doquery :: Process -> String -> b -> (b -> IO (b,Bool)) -> IO b
 :
 | One thing that I am unsure about is whether the column value
 | accessing functions that I specified before
 | 
 |    stringv :: Process -> CInt -> IO String
 |    doublev :: Process -> CInt -> IO Double
 |    intv    :: Process -> CInt -> IO Int
 | 
 | should return actions in the IO monad as above, or instead should
 | be in some other DBQuery monad, that trivially extends the IO monad,
 | but is only valid inside the doquery call. This would have the benefit
 | of restricting the column access functions to inside a query via the
 | type system.

How about introducing a Cursor abstract data type?

    doquery :: Process -> String -> b -> (Cursor -> b -> IO (b, Bool))
               -> IO b
    stringv :: Cursor -> CInt -> IO String
    doublev :: Cursor -> CInt -> IO Double
    intv    :: Cursor -> CInt -> IO Int

This achieves the restriction you're after, because doquery is the
only exported producer of Cursor, and stringv etc. are the only
exported consumers of Cursor.

It also has the benefit that the function you pass to doquery can make
other calls to doquery, without mucking up the 'current row' state.
There would be one current row per Cursor, not one per Process.

 | I'd also probably use a typeclass to specify a single colv function.
 | ie:
 | 
 |    class DBCol a where
 |        colv :: DBQuery a
 | 
 |    instance DBCol String where...
 |    instance DBCol Double where...

Good idea.  The user can always use explicit type signatures to
resolve ambiguity, and even then the code size will be about the same
as with stringv etc.

- Tom