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