On Tue, Dec 2, 2008 at 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!). > > --J. >
Won't (delimited) continuations require support from the JVM itself (unless we resort to using threads and monitors for "simulating" them)? -- pinocchio --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
