Your example doesn't accomplish what dynamic binding does. You don't need to look much further than Clojure / ClojureScript compilers to see cases where trying to propagate information through an environment like you are with ctx is absolutely too tedious, the aspect oriented nature of binding is really what you want.
David On Thu, Sep 5, 2013 at 1:03 PM, Timothy Baldridge <tbaldri...@gmail.com>wrote: > That can easily be done thusly: > > (defn do-stuff [ctx c] > (go (loop [] > (let [v (<! c)] > (swap! ctx process v) > (recur))) > (go (loop [] > (let [v (<! c)] > (swap! ctx process v) > (recur))) > (go (loop [] > (let [v (<! c)] > (swap! ctx process v) > (recur)))))) > > What am I missing here? Every time I've thought I needed binding, I've > been able to find a cleaner, more functionally pure way of doing it that > didn't require binding. > > Timothy > > > On Thu, Sep 5, 2013 at 9:01 AM, David Nolen <dnolen.li...@gmail.com>wrote: > >> I actually disagree a here as core.async brings a pretty nice concurrency >> model into play - I suspect there are instances where you might want to >> construct a series of go blocks with some shared context that you'd rather >> not put into every go loop. >> >> In anycase improved binding support is something I'd like to see in >> ClojureScript and I don't see the downside of keeping the core.async >> behavior the same between Clojure and ClojureScript. >> >> >> On Thu, Sep 5, 2013 at 11:30 AM, Timothy Baldridge >> <tbaldri...@gmail.com>wrote: >> >>> As David said, binding preservation works with Clojure, not with >>> ClojureScript. That being said, while I can see a use for bindings in >>> Clojure (thread-local redef), I fail to see a use-case for binding in >>> ClojureScript. Seems like code could/should be structured in a better way. >>> >>> >>> On Thu, Sep 5, 2013 at 7:54 AM, Jacek Lach >>> <jacek.k.l...@googlemail.com>wrote: >>> >>>> That is not what happens in lein repl: >>>> >>>> user=> (use 'clojure.core.async) >>>> nil >>>> user=> (def pingc (chan)) >>>> #'user/pingc >>>> user=> (def ^:dynamic *text* "OUPS BAD ASYNC") >>>> #'user/*text* >>>> user=> (binding [*text* "good boy"] >>>> #_=> (go (while true >>>> #_=> (<! pingc) >>>> #_=> (println *text*)))) >>>> #<ManyToManyChannel >>>> clojure.core.async.impl.channels.ManyToManyChannel@79d236c2> >>>> user=> (defn ping [] (put! pingc :ping)) >>>> #'user/ping >>>> user=> (ping) >>>> good boy >>>> nil >>>> >>>> It's of course up to core.async to preserve bindings within its body. >>>> But since it tries to pretend to run your `go` code 'as if it was >>>> synchronous', that's probably desirable? >>>> >>>> >>>> On Thursday, September 5, 2013 3:48:10 PM UTC+1, Meikel Brandmeyer >>>> (kotarak) wrote: >>>>> >>>>> Hi, >>>>> >>>>> Am Donnerstag, 5. September 2013 16:36:37 UTC+2 schrieb Mathias Picker: >>>>>> >>>>>> I just tried this test case (from Anderkent on IRC): >>>>>> >>>>>> (def pingc (chan)) >>>>>> >>>>>> (def ^:dynamic *text* "OUPS BAD ASYNC") >>>>>> >>>>>> (binding [*text* "good boy"] >>>>>> (go (while true >>>>>> (<! pingc) >>>>>> (js/alert *text*)))) >>>>>> >>>>>> (defn ping [] >>>>>> (put! pingc :ping)) >>>>>> >>>>>> (ping) >>>>>> >>>>>> and I get "OUPS BAD ASYNC". >>>>>> >>>>>> So, is this bug in cljs core.async? >>>>>> >>>>>> >>>>> This is to be expected, because the binding is reverted after the go >>>>> call returns. So the code in the go block (executed later on) sees the >>>>> old, >>>>> initial binding. >>>>> >>>>> Meikel >>>>> >>>>> >>>> -- >>>> -- >>>> 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 >>>> Note that posts from new members are moderated - please be patient with >>>> your first post. >>>> To unsubscribe from this group, send email to >>>> clojure+unsubscr...@googlegroups.com >>>> For more options, visit this group at >>>> http://groups.google.com/group/clojure?hl=en >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "Clojure" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to clojure+unsubscr...@googlegroups.com. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>> >>> >>> >>> -- >>> “One of the main causes of the fall of the Roman Empire was that–lacking >>> zero–they had no way to indicate successful termination of their C >>> programs.” >>> (Robert Firth) >>> >>> -- >>> -- >>> 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 >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- >> -- >> 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 >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > > -- > -- > 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 > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- -- 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
