xml in fptools?

Simon Marlow 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:
>>>> <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.


More information about the Libraries mailing list