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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
