Re: delimited continuations for web development
Jan Rychter
> On Jun 20, 11:58 am, Jaime Barciela <jbarci...@gmail.com> wrote:
>> Hello Phil,
>>
>> My understanding is that Common Lisp doesn't have support for
>> continuations either and that's why Weblocks uses cl-cont (http://
>> common-lisp.net/project/cl-cont/, a library by the same author) to
>> "fake" them
>>
>> The implication appears to be that you don't need compiler support for
>> them if you have macros (which are, in a way, compiler extensions)
>>
>> I know the Java world has tried and the Resources section here is a
>> good summary:http://www-128.ibm.com/developerworks/java/library/j-cb03216
>>
>> The search continues :)
>>
>> Thanks
>> Jaime
>>
>> On Jun 20, 11:30 am, Phil Jordan <li...@philjordan.eu> wrote:
>>
>> > Jaime Barciela wrote:
>> > > Is there anybody writing or thinking about writing a continuations
>> > > +component-based web framework for Clojure? Although I don't think I
>> > > can carve time to start such a project myself I would be happy to
>> > > contribute to one if it exists.
>>
>> > Clojure doesn't have support for continuations, and as far as I've seen,
>> > nobody has tried anything like it. I have no idea how hard it would be
>> > to implement them, as I'm insufficiently familiar with the JVM's guts.
>>
>> > However, there appear to be some continuation and coroutine libraries
>> > for Java out there. I've never looked into these, so I don't know if
>> > they've got any limitiations that limit the usefulness for this kind of
>> > purpose, but if they work in Java, they should work with Clojure. Google
>> > returns plenty of results to start digging, although at first glance it
>> > worries me that these libraries seem to be written for Java 1.0, which,
>> > I think, didn't yet support native threads and still used Green threads.
>> > (effectively a way of implementing coroutines)
>>
> I know they are all the rage, but I am skeptical of the trend towards
> continuation-based web apps, especially to the degree in which they
> hold state in language-based continuations.
>
> First, it encourages writing apps like the old 70's style terminal
> apps - present a menu, wait for a choice, goto the next screen etc -
> very imperative. Yes, it's easy, and so was that. Then there were
> event-driven interfaces, and the world moved on.
>
> Second, why ever would I want a client's state tied up in something as
> opaque as a language continuation?
>
> Third, there are bound to be things captured in a continuation whose
> viability is extremely time or context dependent - prices,
> availability etc. To the extent you need to care about what is ok from
> the captured stack and what you need to refresh on resumption,
> continuations are insufficient.
>
> Fourth, the continuations freeze the application logic - what if the
> business rules or workflow have changed since the continuation was
> captured? Continuations reflect a view of applications as static.
>
> That's not to say that these frameworks aren't trying to address real
> challenges. Some of the challenges have to do with state-transition/
> workflow management. Some have to do with breaking the 1:1
> relationship between connections and threads, and process re-
> activation. There are some cool Comet capabilities in the Java servlet
> containers that address the latter (some even call themselves
> continuations, but are in reality event-driven).
>
> The short of it is that Clojure is not going to provide continuations
> any time soon, and I encourage Clojure web framework developers to
> think outside the box rather than chase this trend.
Rich,
I'm responding to an old thread, as I've just discovered Clojure, and
I've just been thinking about how to start using it. I also work with
Weblocks (and like it a lot).
Your comments are spot-on if applied to one particular approach to
continuation-based web development. That approach is popular with
Schemers, as Scheme supports first-class continuations as part of the
language. There have been many presentations and demos by schemers where
each HTTP request basically calls a continuation with the entire
application state. This is not what Weblocks does.
Weblocks does something quite different. The continuations we're talking
about are delimited and do not serve the purpose of freezing the
application logic. Also, the sequential/imperative flow you mention
isn't their main purpose. The main goal is to support actions, e.g. code
like this:
(defmethod render-widget-body :before ((w news-story) &rest args)
[...]
(when (display-mode-toggling-enabled w)
(ecase (display-mode-of w)
(:short (link "[+]" (toggle-display-mode w)))
(:full (link "[-]" (toggle-display-mode w)))))
The link macro actually renders a HTML link pointing to the captured
continuation -- an action, which in this case just toggles how the
widget is displayed.
Notice we aren't actually freezing anything and this is not a full
first-class continuation, it doesn't capture the state of our entire
application. It just lets us conveniently execute an action in the
context of a particular user's session. Another area where
continuation-based actions are useful are multi-step flows, which are
present in every web application (think checkout process for example, or
login/signup).
So, these actions make developing web applications much easier and bring
it much closer to desktop GUI development -- where in any decent
language you would use (lambda) instead of (link) to achieve a similar
effect.
I'm not "following trends" here, I simply haven't seen anything nicer or
more convincing for component-based web development. Getting back to the
original topic, I've also been wondering if a library like cl-cont is
possible in Clojure. Notice I'm not talking about full first-class
continuations here.
And I'm all for thinking outside the box, as long as there is something
*better* outside the box (after all, I *am* looking at Clojure in spite
of a heavy investment in CL!).
--J.
PS: incidentally, would it be possible to allow posting for non-members?
Or otherwise enable posting via news.gmane.org? GMANE is a lifesaver for
those of us whose interests require participating in many groups...
Monsieur Pinocchio
Won't (delimited) continuations require support from the JVM itself (unless we resort to using threads and monitors for "simulating" them)?
--
pinocchio
harrison clarke
the hard part about implementing continuations in a language that doesn't already support them is that you're trying to capture it from within.
with a delimited continuation, you're capturing it from the outside, so you don't have that problem.
Rich Hickey
On Dec 2, 12:52 pm, Jan Rychter <j...@rychter.com> wrote:
for Clojure, please try it out and share your experiences.
> PS: incidentally, would it be possible to allow posting for non-members?
> Or otherwise enable posting via news.gmane.org? GMANE is a lifesaver for
> those of us whose interests require participating in many groups...
Rich
Michael Reid
> don't have that problem.
>
continuations based web programming trend as well. Early on when I
learned of Clojure I made a very poor attempt to port cl-cont into
Clojure, but I have not been able to grasp continuations well enough
to do this myself.
I did manage to figure out that cl-cont works by transforming the
delimited continuation into Continuation Passing Style (CPS). This is
a general transform that can be done in (almost?) any language, and
certainly can be done in Clojure.
cl-cont defines a subset of Common Lisp in CPS so that the macro
system could translate most code into CPS, and from there delimited
continuations follow.
The complication with Clojure is the possibility of stack overflow due
to the lack of TCO. With the new trampoline functionality this could
probably be avoided, but I don't understand continuations well enough
to really say if that could work.
It also may be that for the use cases Jan is talking about, it is very
unlikely to blow the stack and so maybe you could just deal with that
as a limitation.
/mike.