xml in fptools?

[Robert Dockins]

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...

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  
contents".

> There have been several discussions on this topic, not everyone  
> shares my views :-)  eg.
>
> http://www.haskell.org//pipermail/haskell-cafe/2003-October/ 
> 005188.html
>
> 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.

> Cheers,
> 	Simon


Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
           -- TMBG