[Haskell-cafe] Takusen and strictness

[Nicolas Frisby]

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 <p.f.moore at gmail.com> wrote:
> On 02/03/07, Bayley, Alistair <Alistair_Bayley at invescoperpetual.co.uk> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>