Tracy R Reed wrote: > Christopher Smith wrote: >> Honestly, I think Monads are the clearest way of representing this, and >> that says something. > > Monads...I still have no clue what they really are. I should finish > reading my Haskell book I guess. And then write some code. > So, two minute (and therefore incomplete) explanation of monads. You've got a function that involves side-effects, let's say "read". What comes back when you invoke read is going to be different each time you invoke it, so you can't treat any two calls to "read" with the same parameters as equivalent (i.e. you could cache the result of one invocation and use it as the result to a subsequent invocation). This is a problem in functional programming, because that is one of the underlying assumptions. The solution is, of course, to add another parameter. Let's call this "n" and we'll say that it represents the "nth invocation of read". So the first time you invoke read you pass in "n" as a zero, the second time you invoke it you pass in "n" as a one, etc. The effect is that each invocation is treated as a distinct instantiation of the function. So far so good. One more problem: you can't reorder reads either. You need to invoke the 0th invocation of read before the 1st invocation, which in turn must be done before the 2nd invocation, etc. So, you also define read with "n" dependent on the computation of read with "n-1". So, while the compiler might choose to look at the results of the 0th read after having done the 1st read, it is forced to invoke the 0th read (and save the result if it needed later) before invoking the 1st read.
--Chris -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
