From: Thomas L. Bevan [mailto:thomas_bevan@toll.com.au]

Ideally, we would have the following.

1/ A high level combinator library for relational calculus built on,

2/ A standard low-level Haskell API i.e. functions like Connection -> String -> ( a -> b -> IO b) -> IO b

3/ Database specific bindings.

The problem is that projections and cartesian products generate new types, at least in the way it was done in HaskellDB. The form the calculus takes would need to be substantially reworked.

I don't see why the generation of new types would cause a problem. Can't we get the calculus library to generate the extraction function at the same time, so that it returns rows of the appropriate type? The generated extraction function would have to be built from standard extraction functions exposed by the low-level API. Although, would this limit the set of types you could use to just those in the low-level API? ***************************************************************** The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. *****************************************************************