The "deep, dark, Aslan magic" of getContents is usually safe to use because it's a read-only operation. Some of the dangerous corners of getContents are: what happens if the file is altered while we read it lazily? This is the sort of question that the sequencing notion of the IO monad is supposed to solve by saying: we read it all at once, so no one can alter it while we do that. (getContents might lock the file--I don't know, but that would introduce its own corner cases).
Can a database fetch have such magic? I think yes, it could probably be implemented the exact same way as getContents. However, whereas concurrent access to files on a filesystem is rare and hence a corner case, concurrent access to a database is usually the norm, and hence not a corner case. In that sense, runSqlLazily might be a helpful function that is often dangerous for A-Consistency-ID reasons. However, ACID-like concerns are not new for DB people, so if the DB server supports transactions, then perhaps Takusen could set up a server-maintained transaction and then read it on-demand. At this point, my arms have become weary from all of the hand-waiving, so I'll ask for discussion now... On 3/2/07, Paul Moore <[EMAIL PROTECTED]> wrote:
On 02/03/07, Bayley, Alistair <[EMAIL PROTECTED]> wrote: > There's a big difference between getContents and Takusen: getContents > has a non-trivial implementation (using unsafeInterleaveIO) that allows > it to return data lazily. Takusen has no such implementation. ... ie, there's deep dark magic involved in the seemingly simple getContents, which isn't easily available to mere mortals (or even semi-immortal library designers). That figures. It's a shame, but not totally unsurprising. > > That's what my earlier code looked like, and I found it harder to > > understand than the getContents/process/put approach. I'm trying to > > explore ways of factoring data manipulation code out of database > > access functions, but maybe that's not the right way of doing it. > > I don't think it's possible to pursue this style of programming with > Takusen. If you do, you'll have to process the entire result-set into a > data structure and then process it, which has obvious memory > implications. Oh, well. It's mostly irrelevant for me anyway, as the data sets I'm actually playing with are small enough that slurping them into memory isn't an issue - so I just choose between a simple and decoupled implementation or a more complex and scalable one, which is a fairly standard optimisation choice. Thanks for clarifying. Paul. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
