On Feb 22, 2007, at 14:56 , Henning Thielemann wrote:
On Wed, 21 Feb 2007 [EMAIL PROTECTED] wrote:
Albert Y. C. Lai wrote:
[EMAIL PROTECTED] wrote:
Albert Y. C. Lai wrote:
If and only if the database is a purely functional immutable data
structure, this can be done. [...]
Many interesting databases are not purely functional immutable;
most
reside in the external world and can spontaneously change
behind your
program's back.
I don't think this is the problem because SQL requests are emitted
atomically anyway. The (Query a) monad here has nothing to do with
mutability of the data base.
The same clock read twice, each reading atomic, can give two
different
results. (Cf. the monadic type signature of
Data.Time.Clock.getCurrentTime.)
The same SELECT to the same database issued twice, each time
atomic, can
give two different results.
Yeah, of course. That's why the function that executes the query
is in
the IO-monad:
query :: GetRec er vr =>
Database -> Query (Rel er) -> IO [Record vr]
Hennings' question is whether the query type 'Query (Rel el)'
really has
to be a monad, not whether the function 'query' has to be in the
IO-monad.
Right.
In other words, 'Query a' just assembles a valid SQL-string,
it does not query or execute anything.
Of course, instead of the DSEL approach "don't execute anything, only
construct a program in a foreign language which does that" it would be
nice to have a database where Haskell is the native query language,
allowing to access the database content with 'map', 'filter' and so
on.
Have you seen CoddFish (http://wiki.di.uminho.pt/twiki/bin/view/
Research/PURe/CoddFish)?
/Björn
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
