Shriram, 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, yc <div class="gmail_quote"> On Mon, Apr 12, 2010 at 5:38 PM, Shriram Krishnamurthi <<a href="mailto:sk@cs.brown.edu" target="_blank">sk@cs.brown.edu</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">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 <div><div></div><div>_________________________________________________ For list-related administrative tasks: <a href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme" target="_blank">http://list.cs.brown.edu/mailman/listinfo/plt-scheme</a> </div></div></blockquote></div>