Most blogs and articles I’ve seen that try to explain continuations get it wrong. They bore you with low level details that confuse you in the first place, or scare you by starting with the premise that “it’s complicated, but I’ll try to make you understand”. I’m not going to do either, I’m actually going to explain continuations in two words, and I want you not to laugh, cry, or vomit on yourself when you read them:

GLORIFIED GOTOs

Oh no, I just said a dirty word, didn’t I. You may have your own irrational fears of the goto statement, but you probably know what they are and how they work:

#include <stdio.h>
int main() {
  int i = 0;
  printf("%d\n", i);
  goto some_label;
  i = 1;
  some_label:
  printf("%d\n", i);
  return 0;
}

The above snippet of working C shows how we can jump to different points in a function. It prints 0 twice instead of 0 followed by 1, as you would expect. Language evolution has mostly deprecated this form of programming through method calls and, more intricately, exception handling. These new practices are really just syntactic sugar on the old goto concept. Hopefully all those who scoff at any mention of goto will one day sit down and realize that they’re a central part of how computers work, but I’m getting off topic. The point is, whether you use gotos or not, they’re extremely simple to understand. In fact, they’re exactly as simple as continuations; let’s re-write the above using those “scary” guys:

def main
  i = 0
  callcc do |label| # callcc gives us ‘label’, a continuation object
    puts i
    label.call # this is our "goto" statement
    i = 1      # we skip this completely
  end          # this is where our "label" would otherwise sit
  puts i
end

To those in the know, this doesn’t really show off the full-extent of callcc’s powers (that comes later), but you can look at "label.call" as the equivalent of "goto label", and the end of the callcc block is where the label would be. That’s basically how continuations work.

If you’re having trouble parsing the above: the little trick to understanding the code is simply realizing that the block that callcc yields is executed immediately, once, and only once. It’s simply there so you can do any one-time initialization with the continuation you’re creating. The end of the block is where any subsequent calls to the yielded continuation object will go, not the block itself.

NOW YOU KNOW.

So what, is it really that simple? Continuations are another way to write gotos? The answer is: pretty much. There are actually only two functional difference that makes them even more powerful than the above C-style gotos, but one that makes them a little less-so.

More Powerful, How?

1. They’re not local to your method. Simply put, we can’t do the following in C:

// a() is called by main()
void a() {
  printf("hello world\n");
  label1:
  printf("then you say...\n");
  b();
}
void b() {
  printf("then I say...\n");
  goto label1;
}

This should print "hello world" followed by "then you say", "then I say", in a never-ending loop. Problem is, it won’t compile. Without getting into the nitty-gritty of why C can’t do this, I’ll just simply show how we can actually get away with it using continuations:

def a
  puts "hello world"
  callcc {|cc| $label1 = cc } # pretend this says "label1:"
  puts "then you say..."
  b
end

def b
  puts "then I say"
  $label1.call # pretend this says "goto label1"
end

As the comments indicate, this is almost a one-to-one translation of the C code above. Our continuation object is set to a global variable, essentially making it a “global label” that can be goto’d by running the method #call (picture it as “label.goto” instead of #call).

2. They maintain stack-frame state. That’s the reason why labels in C are local to a function, because you can’t just jump between functions without switching stack frames. Actually, there are tricks in C to do just that (namely longjmp and setjmp to jump to arbitrary addresses and continue execution which is actually how continuations are done in C), but we’re focusing on Ruby here, right? Basically, the continuation object yielded from callcc (the {|cc| thing}) contains a snapshot of our stack frame at the point it was yielded at (remember, the block is only yielded that first time). This allows us to jump between methods in a class, between classes, and jump back from a nested call when we are arbitrarily deep in a stack frame.

Anyone Up For A Quick Real World Example?

The last situation is the one with some real world usage. Imagine we’re writing a web framework with a Rails-style before_filter and we want the ability to halt the execution during a filter and jump all the way back up to the router code to find the next matching route. Sinatra (sort-of) does this with the `pass` method, and though it probably doesn’t use continuations to achieve the result, the concept here is a perfect example of wanting to jump back through our stack frames arbitrarily. We could be 3 method calls deep, or we could be 20 method calls deep, but we need to “go to” a specific point in our program execution. Usually, people implement this with try/catch style exception handling (RouteAbortError maybe), but continuations may be a little cleaner depending on the scenario (we might have a method handling the exception 3 method calls up, but we want to jump 7 method calls up to the initial point in code).

Less Powerful, How?

There’s one thing you may have noticed from the initial example, it’s that jumping forward looks different from the example where we jumped backwards. The limitation is that continuations can’t actually jump forwards, at least not between method calls. The reason is that in C, labels are compiled into the program statically, but in Ruby, the continuation objects are created at runtime. This means that we’d need to execute that callcc call in our future method to generate the continuation, but we can’t run code that hasn’t yet been run. In short, continuations are great for jumping back in time, not quite so for jumping forwards.

Final Correction

So I initially called continuations “glorified gotos”. Hopefully this got you to understand the simple concept behind their use; but now I should fess up and modify the definition just a little bit to be slightly more accurate. Instead of glorified gotos, think of continuations as:

GLORIFIED, STATEFUL, BACKWARDS JUMPING, GOTOs

Now that you know what the fuss is about, you can decide to hate continuations all you want.

So Avi Bryant spoke at CUSEC this last week and I was fortunate enough to sit in on a Seaside tutorial that he gave to a couple of people. It got me really interested in this Smalltalk web framework stuff. Smalltalk is of course nothing new except for the fact that it was the first language to have some of the awesome code features we use today, but that’s all in the past, so let’s move on.

The interesting part is that playing with Seaside is completely unlike learning Smalltalk (unless you’ve never seen a language with lambdas). It’s a complete mind-blowing experience on its own level; a revolutionary way to look at web application development, not "let’s do what Ruby on Rails does.. in Smalltalk!". The revolution is in the idea that the statelessness of HTTP need not be transitive. It’s the idea that you shouldn’t have to reconstruct bits and pieces of many web requests and figure out what your user just did. In short, it brings back the workflow based semantics that make desktop app development so much more intuitive by comparison. In shorter: it’s the future. Smalltalk might not be, but these concepts definitely are.

State: Big Deal?

There’s something really sexy about being able to do the following:

AuthRegisterTask>>#go

go

  | user |
  user := self call: AuthRegisterComponent new.
  user username ~= ''
    ifTrue:  [ self inform: ('Good Job ', user username)  ]
    ifFalse: [ self inform: 'You did not register' ]

The code above starts from class AuthRegisterTask, throws you off to a register screen (AuthRegisterComponent) and then returns a new AuthUser object back to the task. The task then validates and sends you off to another inform: page (helper page with some text and a simple "Ok" button that brings you back to the previous page when clicked) with the success/failure results. A total of 4 web requests are happening here from start to finish, but by looking at the code (assuming haven’t seen Seaside before) you would never know it. In fact, it looks like you just created an AuthRegisterComponent object and verified the results— the implementation details of how those results are retrieved are properly hidden from you. They’re hidden because they’re ugly.

AuthRegisterComponent is implemented as:

AuthRegisterComponent>>#renderContentOn:

renderContentOn: html

  | user |
  user := AuthUser new.
  html form: [
    html paragraph with: [
      html span with: 'Username'.
      html textInput on: #username of: user.
      ].
    html paragraph with: [
      html span with: 'Password'.
      html textInput on: #password of: user.
      ].
    html submitButton callback: [ self answer: user ].
    ].

The magic here is in the call: and answer: methods. This is where Seaside communicates (continuation style) between requests by saving and restoring state like a conventional application would.

Seaside: Pages are not Islands

Of course the example I used wasn’t perfect, but it’s the shortest illustration I can come up with right now. A much more appropriate (and much longer) example would be a 3+ page wizard style registration where the user might follow one of many possible flow graphs to complete the form. Seaside would handle this with ease because it does not treat pages as islands. In fact, such a wizard would be as easy as implementing one in Swing, or using some Neatbeans auto-wizardifier because the logic and implementation would be equivalent. This is not the case when dealing with the web. You usually have to hack your session and throw tons of state in there to emulate what continuations do in a very clean fashion.

AJAX WAT? AJAX Where Art Thou.

In researching the necessity for such behaviour, I came across an interesting post from Avi himself (dating to 2007) where he states that AJAX trumps most (not all) of the benefits of continuations. It is indeed true that AJAX does emulate the concept of statefulness in some sense, but I’d say AJAX is not nearly as elegant as the above code. Using JavaScript to make requests for tiny tidbits of data, or using JavaScript as glue to throw back to the browser, is almost the opposite of elegant. AJAX surely has it’s place, but I’d rather see more of the above than more crappy && broken JS.

Continuations FTW?

Moral of the story: you should learn continuations because they will blow your mind.