[Haskell-cafe] Using Template Haskell to make type-safe database access

[Wouter Swierstra]

Hi Mads,

>> I think there may a bit of problem with the approach you suggest: as
>> the type returned by the query is computed by the SQL server (if I
>> understand you correctly), it's very hard to do anything with the
>> result of the query - the Haskell compiler has no idea what type the
>> result has, so you can't do anything with it. I think it makes much
>> more sense to bookkeep type information on the Haskell side.
>
> But you can ask the SQL server for the type of the result. In the TH
> function you could:

Thanks for your interesting reply.

I'd forgotten that you can do I/O in TH's quotation monad. I agree  
that you can ask the database server for the type that an SQL  
expression will return. I don't understand metaprogramming enough to  
see how computing types with TH effects the rest of your program.

Here's a concrete example. Suppose you have a query q that, when  
performed, will return a table storing integers. I can see how you can  
ask the SQL server for the type of the query, parse the response, and  
compute the Haskell type "[Int]". I'm not sure how to sum the integers  
returned by the query *in Haskell* (I know SQL can sum numbers too,  
but this is a simple example). What would happen when you apply  
Haskell's sum function to the result of the query? Does TH do enough  
compile time execution to see that the result is well-typed?

Having the SQL server compute types for you does have other drawbacks,  
I think. For example, suppose your query projects out a field that  
does not exist. An error like that will only get caught once you ask  
the server for the type of your SQL expression. If you keep track of  
the types in Haskell, you can catch these errors earlier; Haskell's  
type system can pinpoint which part of the query is accessing the  
wrong field. I feel that if you really care about the type of your  
queries, you should guarantee type correctness by construction, rather  
than check it as an afterthought.

> Of cause it all requires that the database have identical metadata at
> run and compile -time. Either using the same database or a copy.  
> Though
> one should note that HaskellDB has the same disadvantage. Actually  
> it do
> not seem much of a disadvantage it all, as most code accessing SQL
> databases depends on database metadata anyway.

Perhaps I should explain my own thoughts on the subject a bit better.  
I got interested in this problem because I think it makes a nice  
example of dependent types "in the real world" - you really want to  
compute the *type* of a table based on the *value* of an SQL DESCRIBE.  
Nicolas Oury and I have written a draft paper describing some of our  
ideas:

http://www.cs.nott.ac.uk/~wss/Publications/ThePowerOfPi.pdf

Any comments are very welcome! Our proposal is not as nice as it could  
be (we would really like to have quotient types), but I hope it hints  
at what is possible.

   Wouter

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.