|The littlest Schemer
||[Jan. 27th, 2009|08:25 am]
One of my classmates: *writing some code on the board* Okay, so I thought that this
k here was a continuation, but Dan says that it isn't.
Dan: No, it's not a continuation. It's a context.
Lindsey: What's a context?
Dan: *draws a diagram on the board*
Lindsey: Well, that looks like a piece of code with a hole in it.
Lindsey: But that's how I think of continuations!
Everyone: No. Well...um.
Lindsey: Okay, um. What is the relationship between context and continuation?
Dan: Sounds like you have your thesis topic!
Inside-out contexts. Would those be analogous to inside-out objects
? "[T]he whole point of an inside-out object is that its attributes are stored in allocated hashes that are not actually located inside the object. That's precisely how it achieves secure encapsulation: by not sending the attributes out into the client code."
Supporting evidence from EoPL3
: "Continuations are an abstraction of the notion of control context, much as environments are an abstraction of data contexts."
I feel like I'm right on the edge of getting it.
Hm. Interesting. I hadn't seen inside-out objects before.
Rather, the evidence for what I'd suggested came from a draft of Felleisen and Flatt's Programming Languages and Lambda Calculi
. Section 6.3 of that text explains the derivation of the CK machine from the CC machine by the addition of the continuation register and the inside-out nature of it relative to the evaluation context. I'd definitely suggest taking a look at that section.
And later on in chapter 8, they do make the same parallel as EoPL3 between closures for data and continuations for control:
[speaking of the CEK machine] There is, however, one “strange” aspect of the machine: the K register. The C and E registers correspond closely to constructs in the language. The C register contains an expression, which programmers can form at will, and the E register contains an environment, which a programmer can capture using a lambda (to form a closure). But the K register does not correspond to anything that the programmer can write or capture within the language. What if we add a construct to the language for capturing the current continuation?
I think I was on the wrong track with inside-out objects. "Inside-out" is useful as a way to explain what happens to a program when we write it in continuation-passing style. But as for continuation vs. context, Will
finally explained it to me this way: contexts are a static, syntactic notion, whereas continuations are a dynamic, run-time notion.
Moreover, it turns out that there's actually debate about what is really a continuation and what isn't. Dan wasn't entirely kidding about the thesis topic thing. So I don't feel so bad about being confused!