xml in fptools?
robdockins at fastmail.fm
Fri May 26 09:57:33 EDT 2006
On May 26, 2006, at 6:52 AM, Simon Marlow wrote:
> Duncan Coutts wrote:
>> On Thu, 2006-05-25 at 16:41 -0700, Ashley Yakeley wrote:
>>> Malcolm Wallace wrote:
>>>> Oh, I always assume lazy I/O. It is one of the most useful
>>>> parts of
>>>> Haskell, and I rely on it all the time for both interactivity and
>>>> avoidance of space problems.
>>> Lazy I/O is problematic and probably a bad idea for libraries:
>> Assuming we do have imprecise exceptions what is wrong with lazy IO?
> I'm not even certain that lazy I/O doesn't upset referential
> transparency. It seems hard to construct a concrete counter
> example though. My intuition is something like this: if evaluating
> a thunk can cause IO to take place, then the act of evaluating that
> thunk might affect the value of another lazy I/O computation, and
> hence it should be possible to get different results by evaluating
> the thunks in a different order. I'm concerned that in the
> presence of dependencies between lazy I/O computations, the order
> of evaluation might be visible.
I'm personally with you on this one. However, I think it is mostly
just a problem with current state-of-the-art filesysems. We could
solve this problem with a filesystem that models files as persistent
data structures (on-disk ropes maybe?). Then "writing" to a file
just creates a new version of the persistent datastructure and
updates the "name table" to point to the newest version; in fact,
updating the name would be optional! I can think of a couple of use
cases for modifying on-disk files and keeping them private to my
process. Doing "lazy I/O" on a file just means keeping a reference
to a particular version of the datastructure instead of getting the
latest one from the name table. Obviously, there's some issues with
garbage collecting unreferenced file versions, but I don't think the
issues are any more complicated than for a journaling FS (caveat: I'm
not at all a filesystem guru; I could be wrong). Actually, the more
I think about it, the more I like this idea...
Anyway, what I'm saying is that I think a filesystem/OS that supports
persistent files could solve the problems with lazy I/O. After all,
the proof obligation incurred by using lazy I/O is essentially "this
file will not change between now and the last reference I make to its
> There have been several discussions on this topic, not everyone
> shares my views :-) eg.
> Actually, in a way I really hope I'm wrong. I would love to use
> lazy I/O, but I believe we need to have a good story for error
> handling and possible evaluation-order issues first.
Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
More information about the Libraries