On Dec 2, 12:52 pm, Jan Rychter <[EMAIL PROTECTED]> wrote:
> Rich Hickey <[EMAIL PROTECTED]> writes:
> > On Jun 20, 11:58 am, Jaime Barciela <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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!).
>
I'm not trying to discourage anything. If you think this is a good fit
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...
Doing so would open a portal for spam, so I'm disinclined.
Rich
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
