Continuations: One Control Flow Construct to Rule Them All | Hacker News Reader

Continuations: One Control Flow Construct to Rule Them All

blog.bytefreeze.com

42 pointsPieSquared23 comments

Sigh. I'm 43 years old and only really grasped closures this January. It's going to take another ten years for my continuation epiphany.

This is what happens when you start with BASIC.

Continuations sound confusing because they give you an explicit handle for something that most languages don't let you reference directly: who gets the result of the current computation.

Are you familiar with setjmp/longjmp in C? Continuations are similar, but allow longjmp-ing to the same point multiple times. As you might expect, this gives you a lot of flexibility in defining control constructs.

You can implement exceptions easily via continuations - pass along an alternative continuation to receive errors. Continuations are more general than exceptions, backtracking, co-routining, etc., but this generality can make them seem overly abstract - it can be hard to see what those constructs have in common.

Hey, and don't worry - I started with BASIC too. (I was five or six.) You gotta start somewhere. After you feel comfortable with continuations, try learning about unification. :)

> Continuations sound confusing because they give you an explicit handle for something that most languages don't let you reference directly: who gets the result of the current computation.

Yes, unfortunately continuations don't play nice with lazy evaluation.

How about this? http://www.haskell.org/all_about_monads/html/contmonad.html

Yes, I know about the continuation monad. But that continuations have to be encapsulated in monads is telling.

I have found a discussion about this http://lambda-the-ultimate.org/classic/message10560.html

Now, unification (and matching in general) I get. That's magic on a level my mind can accept.

Also: I envy you your starting at 5 or 6. My parents unfortunately couldn't afford the PDP-11 that would have required in my case.

I had a Commodore-64 and a library card. I was born in '82, though.

Anyway, my point was that Dijkstra's just being a grouchypants when he says that BASIC permanently ruins people's minds for programming. Not even C++ could do that.

Yes. And at least BASIC doesn't give you the illusion of a "powerful language".

Think of a continuation as a copy of the stack (saved at the point the continuation was created) that you can invoke like a function.

When you call it with an argument x, what happens is what would have happened if x was the return value of the expression at the point where the continuation was created.

Oh, I understand it at that level. I did a compilers course in Scheme with Kent Dybvig; I know how continuations are implemented (the whole "there is no single stack" thing) but my programming mind, the not-really-verbal part that actually does the coding, just doesn't grok them.

Just like closures; I knew more or less what they were - but this January I ran into my first situation where I really, truly saw how they made a particular situation easier - like, easier in a way that nothing else did - and since then I can't live without closures. That insight suddenly reorganized everything I thought I knew about programming.

I'm still waiting for that to happen with continuations.

It may never happen. You might never need to use raw continuations when writing user applications. They'd be something you more often used through some library that depended on them. E.g. I never explicitly use continuations in HN.

Yeah, hence my ten-year estimate. Sooner or later I'll end up designing my own language for fun; continuations will probably click then.

(Actually, I'm already designing my own language for fun, but it compiles to Perl, so continuations are still not really on the table.)

In other words, continuations provide necessary infrastructure for adding various constructs to a language, but they're sufficiently general that you're unlikely to use them directly.

Also, the first edition of _Essentials of Programming Languages_ has a great chapter on turning an interpreter into a compiler using continuations (Chapter 12). I hear it got cut from later editions, though.

Well tell us about your closure epiphany. I want to know the details!

It wasn't really all that exciting - I was writing an IRC bot for fun, a Roberts Rules of Order moderator. Well, Roberts Rules of Order imposes a structure on events that requires timing, so for instance, if somebody gets the floor, then one minute or two minutes later, we warn them their time is expiring.

The epiphany was twofold. First, I realized that passing an anonymous function pointer to a queue is a lot more general than defining, say, a bunch of event names. This makes the design of the event queue really lightweight.

The second part of the epiphany was that anonymous function pointers in Perl are closures, with lexical bindings to the environment at the time the pointer is created. So my event queue reduced to a simple list of times and closures - magic! Events are entirely general and you can spin off just the event queue logic as a separate module without restricting any later options about what types of event you'll be queuing. It was probably the most satisfying programming I'd done in a decade.

I should note that I stopped doing programming for my bread and butter in 2003 or 2004, and switched to technical translation instead (easy to quote, no debugging, no disputes about what was done or whether it met the user's expectations - it's like programming for hire without any of the downsides!) So I program for fun and to build my own tools, with the result that a month or two may go by without my writing much of anything. That's lots of time for the subconscious to reorganize between exposures, so essentially I'm relearning programming a couple of times a year. Lately I think I'm getting kind of good at it.

Truth is, the idea isn't difficult, it's just very difficult to explain well.

I would suggest that you learn some basic Scheme, download an interpreter, and just play around with it. Try a few things with call-with-current-continuation. Try to figure out the examples on Wikipedia. It'll might take a few hours of toying with it over a few days, but you'll get it. Don't be discouraged :)

As I said elsewhere, that's not enough. I wrote a Scheme compiler in a class with Kent Dybvig way back in the stone age. I used Scheme in my AI classes in the same degree program.

What I need - and what I suspect will take a lot longer - is an actual situation where continuations solve some problem I've encountered. That's when I'll get them, but not earlier, in my experience.

The continuation based approach to web-servers could be interesting for you. And some parsing techniques get easier with continuations, too.

Yeah, the web-server continuation thing rings a bell; I should probably look that up again.

Conditional Jump: Another Control Flow Construct to Rule Them All

Not another, pretty much the same. If you add to "goto" the required stuff to play nice with closures, you get a continuation.

Was that Functional Completeness not obvious in my joke?

Except that in this case, they're not quite as equivalent as NAND / NOR are — continuations assume a lot more "required stuff" (as you put it) than just a basic memory space, a means to test values, and the ability to set the program counter.

That is if you approach the requirements from the implementation point of view. In theory continuations aren't really that much more complex than Gotos.

Reply on news.ycombinator.com