[plt-scheme] web programming, continuation, CPS transform, etc.

Hi All,

Thanks all for your interest in the PLT Web work.  Sorry for coming
late to this party.

Matthias and others have answered some of the questions raised.  I'll
repeat some of those anwers, but also answer a few questions
differently.

Yin-So asks

> 1) Although these paper were published a while ago, it seems that the
> findings have not made their way into PLT web server implementation - is
> that correct?  i.e. I want to confirm that the limitation described in the
> papers still exist in PLT web server (at least as of v360).

These are two different questions.  On the one hand, those ideas have
not made it into the distribution in any serious way (more below).  On
the other hand, there *have* been approaches to tackle some of these
issues -- see, for instance, the thread on "web-server memory use"
happening concurrently on this list.

> 2) None of these paper actually publish the implementations - I am curious
> if the implementations are available somewhere?  If they are not for
> whatever reasons, I understand, but just want to know if it was my own
> inability to find the source (but definitely interested to study how it's
> done, see #3).

Not really available, because they've suffered from bit-rot.

> 3) Are there good links/pointers/implementations on CPS and ANF
> transformation?

I think Matthias has already handled this.

> 4) Is PLT web server moving toward the paper's findings?  If not, why not?

We found it onerous to maintain a source-to-source compiler for all of
PLT Scheme, since PLT Scheme has grown into a sizeable language.
Also, for *many* applications, the existing server infrastructure is
fine.  But then there is Jay's attempt to resurrect Greg's
continuation-mark implementation.

> > Partly due to manpower. See above. To some extent, we really need to
> > design a full-fledged web language based on Scheme that makes good
> > use of continuations.
>
> I am not sure if I follow... Are you saying that the direction of PLT web
> server focus only on continuation?  By that I mean that I infer that CPS/ANF
> is outside of the research scope w.r.t to PLT web server.

It's not outside the scope.  The CPS or ANF+continuation-mark
techniques are simply different implementation methods to take you to
the same end-point (of harnessing continuations).  They do happen to
have very different properties in terms of "ilities": resources,
bookmarks, and so on.

> (just my 2 cents) From a practitioner perspective, AJAX does provide some
> simplifications in web development, but also complicates the structure of
> the code especially in situations where one needs to handle both ajax and
> non-ajax capable browsers [...]

More on this below.

Grant Rettke wrote:

> My take is that continuations are more about capturing state and
> making the program easier to understand. AJAX achieves neither of
> these goals, in fact, quite the opposite!

Matthias is using state in a very specific, technical sense.  In that
sense, continuations do not capture state; they capture "everything
but" state.  If you're using "state" in a more informal sense to mean
"the current situation of the program", then yes, continuations do
capture that, but only partially.  For instance, a continuation does
not capture the content of a shopping cart; this is why two different
continuations both modify the same shopping cart.  That shopping cart
is precisely what Matthias calls "state".

Does that make sense?

Matthias is referring you to a few books you can read to learn more.
Because I am biased, I would point you to mine, which is available in
full and free on the Web:

http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/

The material on state is written to, I hope, be relatively accessible
to someone who is more of a developer than a researcher.  Furthermore,
the book also has a chapter on continuations and the Web, and you may
find it fruitful to browse that, also.

[Stay tuned for a major announcement regarding this book in the coming
weeks, which I will post to this list.]

Once you have been through both of these, you may find it instructive
to read our journal paper on the PLT server:

http://www.cs.brown.edu/~sk/Publications/Papers/Published/khmgpf-impl-use-plt-web-server-journal/

> Your take on AJAX programming is interesting. Would you say that AJAX
> makes web development easier, then?

Matthias said yes; I would say no.  Ajax makes user-perceived
performance better; but Ajax does not make *development* easier, it
makes it harder.

Worse, at this point, we have no story corresponding for Ajax
corresponding to what the PLT Web server infrastructure represents for
traditional, synchronous Web programs.  For this reason we've embarked
on a new language, Flapjax:

  http://www.flapjax-lang.org/

The idea is to tease out the linguistic primitives underlying Ajax
applications and reduce them to a small set of operations, just as we
have done for synchronous apps.

Matthias also said

> As far as we are concerned, the exploration of continuation in the
> context of interactive web programming was our primary motivation to
> do research in this area.
> We have done other things for the web server, but I wouldn't consider
> them 'research.'

which is not quite right.  We have done several other things that are
research.  One is very directly related to the Web server itself,
which is Jay McCarthy's notion of Web cells:

http://www.cs.brown.edu/~sk/Publications/Papers/Published/mk-int-safe-state-web/

In this paper, Jay shows that it is tricky to combine state (in the
formal sense, as Matthias used it) with a notion of Web "components";
in particular, the received PLT wisdom that we have a handle on state
breaks down if you want to build these reusable abstractions.  To
address that, Jay devised a notion of Web cells, which are a kind of
state that behave particularly well in the presence of Web browser
interactions.  This paper describes them, and these have made it into
the distribution.

Based on an earlier theoretical paper --

http://www.cs.brown.edu/~sk/Publications/Papers/Published/kfgf-model-web-inter-error/

-- we also built a very nice model checking (verification) engine that
finds not only traditional errors caught by model checking, but also
interaction-based errors, in Web programs:

http://www.cs.brown.edu/~sk/Publications/Papers/Published/lk-verif-inter-web-prog/

The code for this was recently revived by Arjun Guha.

Finally, based on a repeated pattern of error I spotted in our Web
programs, we went off to explore access control issues.  We have built
quite a sophisticated suite of analysis tools for access control
policies.  Though the policies are written not in Scheme but in a
domain-specific language called XACML, the tool itself is written in
Scheme, which is second best (-:.  You can download that, too:

http://www.cs.brown.edu/research/plt/software/margrave/

Of all these lines of work, three are currently active:

1. Flapjax, the language for Ajax.

2. Margrave, the access control policy analyzer.

3. A more declarative way of writing servers, to compete with and do
much better than the Ruby-on-Rails style.  This is something I'm
investigating with Danny Yoo, whom many of you will recognize from
this list.  We're still in the early stages of this one.

Questions are, as always, welcome.

Shriram