Christopher Smith wrote: > 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. > Probably reads better if you do "s/compiler/program/".
--Chris -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
