Well, okay. Say you want to evaluate a procedure of one argument (that's the only kind you really care about, because of currying). Your procedure looks like this:
(lambda (x) body)
So what do you do? Well, you'd evaluate it by evaluating body, but with x now bound in your environment, right? In other words, this all gets turned into a closure. You give x and body and the current environment to your closure-making machine, and what you get back is a procedure of one argument, but with the updated environment -- x bound to whatever -- baked into the closure.
But now suppose you wanted to pass an environment to the closure, too! This one could be a different environment every time, not like the one that's baked in. (In fact, you can't really call the thing a closure anymore. In my homework, I call it not-a-closure.) Now the new environment overshadows the old one when the closure is called! If you wanted a real closure, this is Very Bad. But if you wanted something that can change as the computation goes along, then maybe it's useful. So what does all this have to do with continuations? I guess I just saw a parallel between situations where you'd want this and situations where you'd want a continuation. Both require passing an extra argument that changes on every call.
And I don't know what reification is. I just calls 'em like I sees 'em.
Also, did you know that "monad" is also a term in music theory? For all intents and purposes just means a single pitch. But by analogy with "dyad" and "triad", it should mean "one-note chord". PARADOX!!
