[plt-scheme] Web framework question

From: YC (yinso.chen at gmail.com)
Date: Mon Apr 12 22:12:33 EDT 2010


IMHO continuation is a great model for the web prior to the wide-spread of
ajax.  With ajax or other RIA mechanism, most of the flow control moves to
the client side.

Of course, ajax breaks if the users turn off javascript.  But this seems
less and less of a concern these days.

Love to know what you think of ajax vs continuation.  Thanks,

On Mon, Apr 12, 2010 at 5:38 PM, Shriram Krishnamurthi <sk at cs.brown.edu>wrote:

> Hi Johan,
> I want to focus on the first issue you raise, since I think Jay has
> done a good job of starting to address the rest.
> I think you're both overstating and understating the continuation
> issue here.  Two pertinent issues:
> - Continuations do not force you into a linear program stream.  It is
> quite common for continuations to represent multiple future options,
> returns to previous points, and so on.  That is, they represent all
> the richness of control flow that programs have.  In this sense, you
> are overstating their limitations.
> - We are very much concerned -- more so than just about anyone else --
> with how programs behave *in the face of user interactions*,
> especially those operations provided by the browser.  Indeed, we made
> the point that the browser buttons and operations are essentially new
> control operators in themselves, imposed from the outside on the
> program by the user (and perhaps not properly imagined by the
> programmer).  We provided a clean account of how one should arrange
> their data relative to what kind of user interaction experience one
> wanted the user to have.  In this sense, you are understating their
> utility for structuring the Web computation in all its glory.
> - We also realized the importance of giving meaning to these
> resumption points (continuations).  Thus we have not one control
> operator (SEND/SUSPEND) but four, to reflect the liveness or deadness
> of the prior and future computation.
> Some of this is hard to discern from our older papers, because we
> thought everyone understood these issues when writing the papers and
> later found that virtually nobody did.  Some things are clearer in our
> journal paper (2006 or 2007), as well as in my talks, some of which
> are linked from my Web page.  I will add that I don't think any other
> continuation-based framework (Seaside, etc.) achieved this level of
> maturity in thinking about computation and state.
> A different way to put it is that you are free to not use any
> continuations at all, and program in a much more traditional sense.
> Sometimes, however, you DO want to arrange for a linear (or other
> structured) flow of control.  For instance, maybe you need to gather
> personal and billing information, you want to do it over three pages
> (to keep the forms simple), and later pages should refer to earlier
> pages (to customize the presented text).  This is a small
> sub-computation that is perfect for structuring using SEND/SUSPEND.
> The rest of your Web app does not need to be written in this style.
> So, I do not see our use of continuations as a hindrance or a
> straightjacket.  Rather, you are free to use the traditional style
> where you want.  However, where you do need to structure a
> (sub-)computation, the continuations are there to make your
> computation's source code clear and hence make the structure explicit.
> Combined with Jay's more recent work on the systems side of things,
> this is all win, no loss.
> We'd love to engage in this discussion further so we can really
> understand your viewpoint and hopefully clarify some of these issues,
> such that you can make the most informed choice.
> Shriram
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20100412/24a71bf5/attachment.html>

Posted on the users mailing list.