[Haskell-beginners] lazy IO in readFile

[Andrew Sackville-West]

sorry, I was distracted for a few days.

On Sat, May 08, 2010 at 11:38:25PM +1200, Stephen Blackheath [to
Haskell-Beginners] wrote

[...]
> 
> In the case of 'readFile', this becomes, "Can I assume that for the life
> of the program, the file's contents will never change?"  (Haskell abides
> in a Zen-like 'eternal now'.)  For a program that reads a config file
> once on startup, the answer might be "yes", and cheating may not
> introduce any risks.

In fact, I know the file will change over the life of the program
because I'm appending to it. Though in theory, I only need to read it
all in once and then after some filtering and other operations, append
to it.

> 
> Perhaps I can give you some more insight by saying this:  Laziness adds
> complexity to the reasoning necessary to understand how your program
> will execute.

yes. I'm with you there.

>  Purity means that this complexity is neutralized and
> becomes the compiler's problem, not yours.  You have to remember that
> while the tiniest little piece of information calculated from the
> contents of your 'readFile' remains unevaluated, the file will not
> close.  That's very difficult to reason about.

indeed.

> 
> Another thing to consider is, if the code you're implementing relies on
> lazy I/O, might you want to use it in a big program?  If so, surely it
> would be better to do it in a more general way to begin with.  One of
> the things monads are especially good for is replacing lazy I/O.
> 
> You might object, "Lazy I/O is so incredibly brilliant, but you are
> telling me I can't use it! That really ruins Haskell for me if one of
> its most amazing features is not allowed!"
> 
> I know this seems very unfair.  But my reply is, "Purity really is
> *that* good. It's even worth giving up lazy I/O for - that's how good it
> is."

I really agree with you, to the extent my limited knowledge and
understanding allow, and so am willing to try to learn this...

> 
> >> I'd recommend using withFile and hGetLine, like this:
> >>
> >> withFile "testfile" ReadMode $ \h -> do
> >>     ...
> >>     l <- hGetLine h

I'm having trouble determining how to put this into the existing
context of a string of filter's and maps where the contents of the
file are used in a predicate to a filter. (if you really want you can
look at my ridiculous code at
http://git.swclan.homelinux.org/rss2email.git)

I suppose that means I need to rethink the structure of my program
(which already seems to be necessary anyway...).

[...]

> A parting thought:  One of the great things about Haskell (compared with
> imperative programming) is that there are dozens of things you don't
> have to reason about any more, so you can concentrate on solving your
> problem.  Do you see what I'm saying?  Why even bother reasoning about
> whether laziness can get you?  Just make everything pure and you don't
> have to. *
> 
> (* I don't want to mislead you and make you think Haskell is something
> it's not.  Therefore I need to add here that you *do* need to reason
> about the *space and CPU usage* of your code in the presence of
> laziness.  IMO this is the only serious cost of using Haskell - the rest
> is benefit.)

thanks for your thoughtful comments.

A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : http://www.haskell.org/pipermail/beginners/attachments/20100514/ffa76ce7/attachment.bin