Aah. ;-) Hello Per, thanks for pointing to the big Roy. I should have someone do this to me every other day until I finally read it ;-)
Looking at you code, I understand why I didn't come up with it - I still have to do some basic Clojure lessions. Very cool. I didnt expect this to be such a few lines. (And thanks for preventing me to fall into that REPL trap.) Now I will try and use it. Thanks and greetings, alux On 15 Apr., 14:55, Per Vognsen <[email protected]> wrote: > The first thing I ever implemented with promises was dataflow > programming in this style. A good read is the chapter on declarative > concurrency in Peter van Roy's Concepts, Techniques and Models of > Computer Programming. Oz has the concept of concurrent > single-assignment variables, which are much the same as promises. > > All you need is this: > > (defn deref-seq [x] > (proxy [clojure.lang.ASeq] [] > (first ([] (first @x))) > (next ([] (next @x))))) > > This works with anything that derefs to a seqable value. For example, > here's how you'd implement your own version of lazy-seq in terms of > the delay form: > > (defmacro lazy-seq* [& body] > `(deref-seq (delay (do ~...@body)))) > > Here's a basic example with promise sequences: > > user> (def p (promise)) > #'user/p > user> (future (doseq [x (promise-seq p)] (println "New element:" x))) > #<core$future_call$reify__2...@dbb638: :pending> > user> (def q (promise)) > #'user/q > user> (do (deliver p (cons 1 (promise-seq q))) nil) > nil > ;; 'New element: 1' is printed by future. > user> (do (deliver q (cons 2 nil)) nil) > nil > ;; 'New element: 2' is printed by future. > > (In case you're wondering, the (do ... nil) is intended to prevent the > REPL from printing (and hence implicitly dereferencing) the tail > promises. This is annoying quirk of the current printer > implementation. When I first played with promise sequences, I changed > print-method for promises so this doesn't happen.) > > With that in place, you can connect a pair of threads with a matched > pair of promises. Indeed, it's easy enough to abstract away most of > the scaffolding for dataflow programming with promise sequences so it > looks much as it does in a language like Oz. > > -Per > > On Thu, Apr 15, 2010 at 7:10 PM, alux <[email protected]> wrote: > > Hello Anniepoo, > > > thank you for the answer. I t made me think in new directions, > > splendid! > > > Its streams, I completely agree. What I still try is mapping this to > > the ubiquitous Clojure-sequences. And what I came up with is seeing > > the stream as blocking lazy sequence of strings (the lines), that can > > then be transformed into blocking lazy sequence of messages (that may > > be multiline, I didn't mentioned that before). > > > And now I'm not sure whether the blocking permits to be a sequence. As > > far as I understand, blocking (in the Clojure world) should be > > restricted to references. And if head and tail of a "seq" are > > references, they dont fit the interface anymore, or do they. > > > Still thinking ;-) > > > Kind regards, alux > > > On 14 Apr., 22:41, Anniepoo <[email protected]> wrote: > >> what you want is just a stream in each direction. > > >> Bob: So, how do you feel about the Smith contract? > >> Fred: It's not a good deal for us > > >> Fred: Do you think we'll have 4 engineers working on it? > >> Bob: Turn left here > >> Bob: No, more like 5 > > >> Fred: at the light? > >> Bob: Yes > > >> I'd make a wrapper around a socket connection. If you want an async > >> call, > >> like Fred's last question "at the light?" then have a different send > >> access that takes two args, > >> (ask-bob "at the light?" (fn [response] ... handle the > >> response....)) > > >> as opposed to > >> (tell-bob "blah blah") > >> that doesn't get a response > >> (after all, you presumably need to know what question Bob is answering > >> 'yes' to) > > >> ask-bob sends bob an id along with the question, and shoves the > >> function into a map with id as key > >> when bob sends a response the function gets called > > >> The recieving end is a good candidate for a multimethod. > >> the dispatch function would somehow parse the message for type > >> and figure out which handler handles it. > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to [email protected] > > Note that posts from new members are moderated - please be patient with > > your first post. > > 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 > > > To unsubscribe, reply using "remove me" as the subject. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. 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
