Anton van Straaten <anton@appsolutions.com> wrote:
+---------------
| Rob Warnock wrote:
| > Don't get me wrong: I still think the "web continuations" *model*
| > is a great way to think about the user/server interactions ...
| > But just because "web
| > continuations" are a good model for *designing* the navigation and
| > interactions doesn't mean that "real" continuations are actually the
| > right way to *implement* the site.
|
| You're right about the model being good, but beyond that, there's a big
| red flag in the above claim. It suggests that having developed a model
| based on continuations, the only way to effectively implement that model
| is to manually map it onto an implementation in which (some of) the
| continuations have been made explicit.
+---------------
Unfortunately, that's already the case. The browser user may be
presented with a single HTML page [a single "call" to the user by
the server, in the web continuations model], but if that page contains
*multiple* HTML forms you end up with the user being able to choose
between as many different continuations as there are HTML forms!!
This means that in the server a "call" to the user has to be able to
reify not just one but *multiple* continuations, something that classic
CALL/CC isn't capable of [at least, not without significant extension].
Now with CPS-transformed code, on the other hand, this all becomes
trivial. One merely does a "jump-with-arguments" (a.k.a. tail call)
to the subroutine [the browser user, in this case] with whatever
arguments are needed, any or all of which can be continuations!!
Problem solved!
But if one is going to CPS-transform the server/user interaction
anyway to accomodate multiple continuations, then there is no longer
any need for "real" continuations on the server side -- the sort
of "faux continuations" that Kenny [and I] talked about are fine.
You still have the *idea* of continuations, but all they are is
an identified set of routines to dispatch to depending on which
HTML form was triggered.
+---------------
| But what makes you think that this mapping can't be automated?
+---------------
Oh, it can be, even in Common Lisp [which is what I've been coding
my "web continuations" code]. E.g., see Paul Graham's book "On Lisp"
for macros to do multi-use continuations in CL. It's just that given
the existence of "calls" to the user that need to provide *multiple*
continuations simultaneously, the simple-minded CALL/CC model becomes
*less* convenient than explicit CPS-conversion!! [IMHO. YMMV.]
And by the way, there is at least one classic programming language
which has shown that programmers are quite able to handle explicit
representation of multiple continuations in the source language: SNOBOL.
In SNOBOL, *every* statement can be explicitly provided with two
continuations, called SUCCESS & FAIL [or a single continuation of
unconditional GOTO or the default of fall-through to the next statement].
The extension to multiple web continuations per HTML page is obvious
and direct.
Or said yet another way, once one has to deal with "calls" containing
multiple continuations, one is half-way an explicit event-driven
finite state machine. To me, the lines between CALL/CC-style
continuations, manual CPS-transformed code, and event-driven finite
state machines are in practice quite blurry -- it's more of a
continuum than a hard choice.
+---------------
| Scheme implementations, in conjunction with theoretical work, have been
| addressing these issues very successfully. For example, SISC and Gambit
| support serializable continuations, and Scheme48 provides native support
| for delimited continuations. These two natural extensions of Scheme's
| continuations address many, perhaps most, of the concerns which people
| raise against first-class continuations.
+---------------
But how do you provide *multiple* continuations using CALL/CC syntax?
+---------------
| Coming back to the question of mapping from a continuation-based model
| to an implementation, we shouldn't forget that we have tools which are
| capable of transforming code written in one style into code written in
| another style. They're called "compilers". It's perfectly possible to
| automatically transform code written with implicit continuations into
| code which makes the continuations explicit in data stored on web pages,
| for example. To do this, all that is required is the well-known and
| easy-to-implement CPS transformation. This ends up being equivalent to
| having support for serializable, first-class continuations, but it
| provides a different way to think about it, which can be helpful.
+---------------
No argument. [See my comments above.] And of course, the Lisp family
of languages make writing such "compilers" relatively simple --
sometimes as simple as an appropriate set of declarative macros!
-Rob
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607