Re: Parallel let form

[Ben Wolfson]

"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> 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
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
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.
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]

[Ben Wolfson]

It's not too hard, though, to write a plet form that first does some analysis on the bindings to see which of them depend on which others. I believe I mentioned this elsewhere in the group as an example of why a macro might want to macroexpand its arguments, because doing that is the simplest way to find out where you've got a binding form. In:

(plet [a 2 b (my-mystery-macro [a 5] a)] b)

if my-mystery-macro introduces a binding for 'a', then the expressions can be evaluated in parallel, since 'a' isn't free in the expression being bound to 'b'; otherwise, 'a' *is* free in that expression and refers to the earlier binding, and the two expressions can't be evaluated in parallel.

[Alan Busby]

Hi All,

You may want to take a look at Prismatic's graph library, it does what you've described above in a slightly different way.

Link: https://github.com/Prismatic/plumbing

[Ben Wolfson]

That library and others like it (e.g., oh, I dunno, babbage) impose more overhead, though, than a simple let form, if you just want to use something one-off in one place.

[Gunnar Völkel]

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.