[Squeak-e] Programming the VM

[Avi Bryant]

On Mon, 3 Feb 2003, Mark S. Miller wrote:

> Jonathan Rees, who did W7, now agrees that default indefinite extent
> continuations are a disaster in the context of general caller/callee
> mutual suspicion. See
> http://www.eros-os.org/pipermail/e-lang/2001-July/005418.html for some
> related points.

> Btw, call/cc with dynamic extent continuations are fine, as with Smalltalk's
> traditional "[:result | ^result]" .
>
> It sounds like there's a genuine conflict here with Seaside, which we need
> to understand better.

Seaside requires indefinite extent continuations to be able to properly
model the interaction style inherent in web applications.  Consider the
common case of a web application putting up a form to gather information.
In Seaside, the act of putting up that form is a method call, that will
then block for user input.  When the user submits, that method
call will return with the values from the form.  The pattern looks like
this:

request := self respondWithForm.

So far, so good - it's an (extremely useful) inversion of the usual
control flow of web applications, but it doesn't present any immediate
problems.

However, say the user hits the back button and submits the same form,
again.  For the semantics to be consistent, this same method call must
return, again, with a new set of values.  Even if this were somehow
implemented without using indefinite extent continuations, it would share
the same problem: the caller has to be prepared to be returned to multiple
times.  This is fundamentally a property not of Seaside but of the
existence of the browser back button.

For some papers on this approach, see

Paul Graunke, Robert Findler, Shriram Krishnamurthi, Matthias Felleisen,
"Automatically Restructuring Programs for the Web"
http://www.ccs.neu.edu/scheme/pubs/ase2001-gfkf.ps.gz

and

Christian Queinnec, "The influence of browsers on evaluators or,
continuations to program web servers"
http://youpou.lip6.fr/queinnec/Papers/webcont.ps.gz