Forum OpenACS Q&A: Continuations for web programming?
I generally know what continuations are from SICP and other Lisp/Scheme books, but I've never worked with them. Nor have I yet read the various papers Vadim referenced, but so far this all sounds interesting, maybe even useful.
Tcl doesn't have first class continuations of course, but presumably they could be added? Or simulated? How hard or ugly would that be? Do Tcl's lack of lexical closure or scoping make it harder?
The referenced thread from the lightweight languages list at shows some very enthusiastic support, but I think I'd need to look at code implementing a real web-development framework using continuations to understand what the supposed big win is really all about, and how it actually works in practice.
E.g., if you want to stuff a whole lot of state into continuations (more than just a helper for a two-page form submit, say) then presumably you get to worry about whether or how to properly store that stuff someplace that won't vanish when your web server restarts, like the RDBMS. So where and how is the dividing line drawn between session state more or less implicitly stored in continuations, and explicitly stored data in the RDBMS?
Who here knows more about this stuff? Thoughts?
You might look into AOLserver 2.3.3 and check out ns_state(I think?). It stored session type information in files, since it is written in tcl, should be easy to port over using nsvs.
- A Wiki version of Vadim's old post.
- Lambda the Ultimate on Using continuations for web programming.
- Dave Roberts on continuations and REST.
- Paul Graham discussing continuation-passing style in Lisp for Web-Based Applications.
- Chris Double gives lots of links on continuation based web servers and the like.
- Norman Ramsey and Simon Peyton Jones explain cheap continuations for C-- (a compiler back-end language), as opposed to (expensive) first class continuations as in Scheme R5RS.
Why does stuff in my RDBMS disappear when my web server restarts? Or more specifically, why don't I experience this?
A lighterweight way to save state information may be desirable, but overkill is really the only problem with the RDBMS.
The big win, as you put in, in the continuation paradigm is that rather than write a scattered set of scripts that respond to an ansynchronous batch of HTML requests, explicitly passing information via hidden form variables or (in OpenACS) session variables stored in cache backed by the RDBMS, you write your code as though you're communicating using synchronous I/O.
The framework handles the problem of issuing the asynchronous I/O requests and the saving of state information across the stateless stream of HTML request.
The size of this "big win" probably is directly proportional to your perception of just how difficult it is to write web UIs the traditional way. Most web UIs for practical sites are quite simple, so the win for desktop GUI applications (which also generally run in a more complex application environment with a rich set of events to respond to and trigger) might be much, much larger ...
I notice that Paul Graham, and most others who talk about the beauty of using continuations or closures for web programming, never mention what happens when their big Lisp (or whatever) server-side web application restarts, which makes me suspect that they're just keeping them in memory, no persistence at all. Which obviously is Not Good Enough much of the time. ("Why is my shopping cart empty all of a sudden?")
Continuations do nothing to solve the problem of storing of state. It simply makes the storing of state implicit through the use of language constructs which invoke state-saving and control-flow mechanisms in a way that let you program in a more natural style.
You could, for instance, use our existing session storage and other centralized state-management procedures as the base for implementing continuation semantics in some sort of Tcl+ extension designed to run in our environment.
So that brings me back to my statement above: are web GUIs, at least for the kind of sites you write today and expect to write in the future, complex enough to worry about?
In this case, though, my perception is that implementation of a practical scheme might be quite difficult, while the payoff for the kind of sites I am involved in would be rather low because they're just not that sophisticated when it comes to UI.
But as I mentioned above, handling state management for the GUI of a complex desktop application might have a much larger payoff.
Some (most?) of the people espousing web continuations definitely seem to be trying to do richer more GUI-like web UI, or trying to make the same code work identically both on the web and on the desktop. So that does seem to line up with Don's, "probably a bigger win for desktop GUI apps" thesis.
On the "are the web GUIs your write complex enough to worry about" question, well, I personally have been spending only small percentages of my programming time on web work of any sort (much less complicated web UIs) for a few years now, so I'm clearly the wrong person to answer that question. But I'm definitely interested in what others think about it, as in Don's posts above. :)
Most of the continuation based web servers I know about still store 'application state' in the database. State related to application logic, GUI, etc is often what is stored in the continuation.
If the language or implementation supports serializable continuations then the continuation itself can be stored in the database too so nothing is lost on reboot. This is what I do in a Scheme based system for example.
The main win is being able to code the application in an procedural manner without having to break up the logic into HTTP request/response. Whether this is a win or not depends on how experienced you are doing web apps the traditional way I guess.
If you want to know details on the implementation of a continuation based web server a couple of helpful links might be:
Both present basic implementation ideas in Scheme.
Coroutines and continuations are related concepts. Roberto Ierusalimschy's papers include his 1994 "Revisiting Coroutines", with a very nice overview of coroutine stuff. It seems to touch on every flavor of coroutine other than Simon Peyton Jones's "cheap continuations". (He's also the creator of Lua.)