<greenash@yahoo.com> wrote:
+---------------
| What am I missing by using Scheme (and Scheme web frameworks in
| particular) instead of Lisp?  I could easily point out what people
| miss by using Lisp instead of Scheme: continuations.
+---------------

Actually, despite the excellent papers by Queinnec, and by
Felleisen et al, when it comes to web applications having
Scheme-style continuations turns out *not* to really be a
significant advantage after all!!

Yes, it is extremely important when designing a web app to *think*
in terms of the user's "Submit" of a form as calling a continuation
in the server -- it helps a lot with keeping the behavior sane from
the user's point of view, especially when the user has multiple
browser windows open to different pages within the app[1] -- but you
don't need a "real" continuation in the server to do that, only a
function that handles "the next transition" of the state machine
you're implementing. But you don't need "real" continuations in
the web app to derive the benefit from this way of thinking.

In fact, the big *problem* that arises when using real Scheme-style
continuations in web apps [seldom discussed by their advocates, or
quickly glossed over] is that keeping real continuations around
chews up memory, a finite resource, and to avoid (possibly even
inadvertant) DoS attacks you have to have some kind of "expiration"
and/or "GC" of the outstanding continuations, which puts you right
back in the same problem of needing a state-transition function to
call if the continuation has "timed out".

IME, the correct solution is to: (1) do your initial design *as if*
you were using real continuations; but then, (2) CPS-transform the 
design[2] into a state machine with input-value-carrying transitions
[and once you have done this, CL works as well as Scheme]; (3) choose
an externalizable representation for the states and the permitted
transitions [that is, the CPS'd "continuations"]; then either
(4a) store the "continuation" in the web page delivered to the user
(encrypted and authenticated as much as necessary to prevent spoofing
and/or replay attacks), or (4b) store the "continuation" in a real
database, but recognize the need to perform "GC" on the stored
"continuations", with the inevitable upset that will cause to a
few users when their form "times out".

I tend to use "4a", but YMMV.


-Rob

[1] Queinnec, and to a lesser extent Felleisen et al, shows in
    detail why this almost certainly means you must *NOT* use cookies!!
    [Hint: Cookies are per-browser, not per page displayed.]

[2] Either formally/automagically or informally/manually. I have
    found in my CL-based web apps that the latter is not particularly
    difficult or error-prone.

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607