It is not broken. It fulfills the discussed goal of having independent parallel calls in a "let"-like macro. Thus the name plet. Using a previous binding in another binding of plet was no goal. Therefore you can use the normal "let" macro.
In a library one should add the intention to use it only for independent parallel calls to the doc string. Am Samstag, 27. April 2013 17:59:13 UTC+2 schrieb Ben: > > "guv" is broken if your let form introduces bindings that depend on > earlier bindings: > > user=> (plet [a 2 b a] b) > CompilerException java.lang.RuntimeException: Unable to resolve symbol: a > in this context, compiling:(NO_SOURCE_PATH:1) > > user=> (clojure.pprint/pprint (macroexpand-1 '(plet [a 2 b a] b))) > (clojure.core/let > [G__364 > (clojure.core/future 2) > G__365 > (clojure.core/future a) ;;; oops! > a > @G__364 > b > @G__365] > b) > nil > user=> > > In fact, both of them are broken in this way. > > > > On Sat, Apr 27, 2013 at 6:55 AM, Glen Mailer <glen...@gmail.com<javascript:> > > wrote: > >> Hi All, >> >> I was recently looking at how to make better use of parallelisation for >> simple tasks in my compojure app, I had a construction similar to the >> following: >> >> (views/some-view (api/api-call-1) (api/api-call-2) (api/api-call-3)) >> >> It seemed that the easiest way to introduce some parallelism here would >> be in the style of a let form: >> >> (let [result-1 (api/api-call-1) >> result-2 (api/api-call-2) >> result-3 (api/api-call-3)] >> (views/some-view result-1 result-2 result-3) >> >> There doesn't appear to be anything in core that does, this - after a >> brief discussion in the IRC channel, I received the following two >> suggestions: https://gist.github.com/jcromartie/5459350 and >> https://gist.github.com/guv/5459364 >> >> I ended up going with the approach from "guv", as I understood it better >> - and I moved the let form inside the view function to cut down on the >> repetition a bit. >> >> Now, to my actual questions: >> >> What are the differences between the pmap approach and the futures >> approach? >> >> And would a construction like this be useful in core? If so, how does it >> potentially get there? >> >> >> Thanks >> Glen Mailer >> Budding Clojurer >> >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com<javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > Ben Wolfson > "Human kind has used its intelligence to vary the flavour of drinks, which > may be sweet, aromatic, fermented or spirit-based. ... Family and social > life also offer numerous other occasions to consume drinks for pleasure." > [Larousse, "Drink" entry] > > -- -- 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.
