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 onl
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.
On Sat, Apr 27, 2013 at 5:05 PM, Alan Busby wrote:
> Hi All,
>
> You may want to take a look at Prismatic's graph library, i
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
On Sun, Apr 28, 2013 at 1:04 AM, Ben Wolfson wrote:
> It's not too hard, though, to write a plet form that first does s
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 t
"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))
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 her
