xml in fptools?
simonmarhaskell at gmail.com
Fri May 26 11:15:58 EDT 2006
Robert Dockins wrote:
> 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...
Haskell prevents you from opening a file for writing while you already
have it open for reading (even if the reading is being done lazily).
This is an oft-forgotten part of the Haskell I/O library specification,
perhaps because only GHC implements it (and even GHC doesn't implement
it on all platforms).
But in principle I agree, we would like to think of hGetContents as
pulling lazilly from an immutable array of bytes, and if that were the
case then there would be no problem.
More information about the Libraries