To be fair, while it's great that Functor et al. are available to help solve problems like that with a Tree data structure, in the present context it mostly shows that a trivial example was used to illustrate the problem. Unless I'm missing how this generic fold functionality solves the more general problem. Quoth Alberto G. Corona,

... There is no such problem in imperative languages, which work ever in an hardwired IO monad.

Or to look at it from the other direction, the problem with Haskell is that it allows the programmer to write non-IO functions. To the extent that's a real problem, the solution would obviously be to exercise some restraint with the pure code and write more in the IO monad. If you will humor me, we understand that this code is equally satisfactory from a mathematical perspective and there's no crime in it. But does it help with the `flags problem?' Suppose that functions f and g both have IO types; f calls g, and g has optional behavior depending on some IO value computed previously, the flag. The way I understand it, I can accomplish this without passing the flag around: with an IORef. What's less clear to me is whether Haskell really supports the module level accessible IORef value I need. Also known as "top level mutable state." Is the NOINLINE pragma I've been using with GHC, really a sound and reliable practice that we're reasonably confident will be supported by other compilers? It feels to me like I'm pulling a weird trick, to do something that's trivial in other programming languages. Maybe that's part of the problem, that imperative programming receives something a little short of full support in Haskell, inasmuch as basic features like top level mutable state require relatively arcane incantations. Donn