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

Hi Shriram -

thanks for joining the party and provide your thoughts ;)  Please see
inline...

On 5/1/07, Shriram Krishnamurthi < sk at cs.brown.edu > wrote:
>
>
> > 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.


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).

> 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.


(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.

> 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?


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.

> 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/<http://www.cs.brown.edu/%7Esk/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/
>
> <http://www.cs.brown.edu/%7Esk/Publications/Papers/Published/khmgpf-impl-use-plt-web-server-journal/>



Thanks for the links ;)

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


Agreed.

> 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.


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? ;)

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.


Love to see this in action ;)

Thanks,
yinso
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20070501/c1f87044/attachment.html>