Hi Shriram - thanks for joining the party and provide your thoughts ;)  Please see inline... <div>On 5/1/07, Shriram Krishnamurthi <<a href="mailto:sk@cs.brown.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> sk@cs.brown.edu </a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > 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.</blockquote><div> It makes sense this is a onerous work - I worked out that it requires knowledge of PLT scheme itself and then I stopped (an aside - I guess what you are saying is that PLT is not using CPS underneath ;P).  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> 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.</blockquote><div> (2 more cents from a practitioner) The ilities are of huge interest for developers wanting to develop huge scale web applications.  I love the concept of continuation, and I suspect the scalability is higher than I give it credit for currently, but I haven't justified diving in head first due to the fear of committing to a ceiling on scalability in architecture that I can't fix. </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> 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? </blockquote><div> Okay - so state for you means the same for me - this is a good thing ;)  I will retract my last question which ask this specific topic because I thought the understanding is different.  And yes I can see why continuation doesn't capture state, but I intuitively understand the informal sense Grant refers to. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> 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: <a href="http://www.cs.brown.edu/%7Esk/Publications/Books/ProgLangs/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/</a> > 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: <a href="http://www.cs.brown.edu/%7Esk/Publications/Papers/Published/khmgpf-impl-use-plt-web-server-journal/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://www.cs.brown.edu/~sk/Publications/Papers/Published/khmgpf-impl-use-plt-web-server-journal/ </a></blockquote><div> Thanks for the links ;)  </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Matthias said yes; I would say no.  Ajax makes user-perceived > performance better; but Ajax does not make *development* easier, it > makes it harder.</blockquote><div> Agreed. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> 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:   <a href="http://www.flapjax-lang.org/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.flapjax-lang.org/</a> > 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.</blockquote><div> I saw it - it's cool.  From my perspective AJAX complicates the design of web software even further as one has to account for multiple levels of browser/server interaction.  Unification of browser & server level programming ( e.g. write once, work as ajax and as non-ajax) is something that's also of big interest for developers, but perhaps this is more fitted toward implementation than necessarily research? ;) </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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.</blockquote><div> Love to see this in action ;)  Thanks, yinso </div></div>