Database interface

[Tom Pledger]

Tim Docker writes:
 | Tom Pledger writes:
 | 
 |  > 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]
 | 
 | Can you explain what the constraint does here?

Yes.  It soothes my superstitious fears about unsafeInterleaveIO.

I imagined that:

  - doquery (like getContents) uses unsafeInterleaveIO to make the
    resulting list lazy, i.e. avoid grabbing all the rows at the
    outset,

  - the unsafe interleaving would *somehow* get into the extraction
    action, and

  - the current row could be overwritten while some stringv (etc.)
    actions on it were yet to happen, so

  - a good safety measure would be to force evaluation (hence DeepSeq)
    of each list element before overwriting the current row.

But now that you ask, I think it's possible for doquery to stop the
unsafeInterleaveIO from leaking into the extraction action, so the
DeepSeq would only protect users from shooting themselves in the foot
with weird queries like this

    doquery p "select s from t" (unsafeInterleaveIO (stringv p 1))
    -- DeepSeq would allow doquery to undo the effect of unsafeInterleaveIO

or this

    [a1, a2] <- doquery p "select s from t" (return (stringv p 1))
    s2 <- a2
    s1 <- a1
    -- DeepSeq would disallow this at compile time

- Tom