?

Log in

No account? Create an account
The littlest Schemer - Lindsey Kuper [entries|archive|friends|userinfo]
Lindsey Kuper

[ website | composition.al ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

The littlest Schemer [Jan. 27th, 2009|08:25 am]
Lindsey Kuper
[Tags|]

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.
Everyone: Yes.
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!

*sigh*

LinkReply

Comments:
[User Picture]From: pixelherder
2009-01-29 06:38 am (UTC)
Looking over my old notes on such things, I've seen continuations described as inside-out contexts (and thus values/expressions).

Dunno if that helps at all. It's been three years since my PL class.
(Reply) (Thread)
[User Picture]From: lindseykuper
2009-01-30 07:03 am (UTC)
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.
(Reply) (Parent) (Thread)
[User Picture]From: pixelherder
2009-01-30 08:32 pm (UTC)
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?

(Reply) (Parent) (Thread)
[User Picture]From: lindseykuper
2009-03-15 02:52 pm (UTC)
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!
(Reply) (Parent) (Thread)