xml in fptools?

[Simon Marlow]

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:
>>>> <http://haskell.org/pipermail/haskell/2006-May/017998.html>
>>>
>>> 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.

Cheers,
	Simon