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