> foldr, foldM, etc. derive a recursive computation from the > recursive structure of an input list, so you have to feed > one in. If you want to bypass the list, you could use > IO-observations (getLine, isEOF) instead of list > observations (head/tail, null):
Yes you can define it, I should have been a bit more direct. It seems to me that there's something odd about the way the IO monad interacts with bulk operations on files. In particular, it seems odd that getContents should ever be the easiest way of tackling something, rather than some natural operation on Monads. Doing something to each line of a file is such a common kind of computation that it ought to be easy! It also seems wrong that end of file should be an exception -- after all, for most files other than a terminal or "special file", having an end is the norm. As a result, the definition you gave strikes me as awkward (no fault of yours!). It suggests to me that a Monad isn't quite enough. One of the great things about fold is that you don't have to code the test for the end: it's encapsulated in the higher-order function. Shouldn't there be the same for IO? > Whether that is a real fold, or what the real fold/unfold would > look like, I leave to others;-) I suppose that was part of my real question, aimed at the others who've got the mental processing power to answer such things. Cheers, Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ +44 1223 570179 (after 14:00 only, please!) _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
