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