I'm new to looking at the source code, and I see dynamic vars being used for binding context for the environment(s). Just curious is there a reason that dynamic vars were used, necessitating binding, instead of something like atoms to represent the values that could be passed into the functions?

@tomjkidd we use atoms, kind of unrelated to how/why we use dynamic bindings.

if you have a more specific inquiry, then ask that.

@dnolen do you use Cursive when working on clojurescript?

maybe you have run into https://github.com/cursive-ide/cursive/issues/1554 as well?

or anyone else here running Cursive for the cljs project?

@dnolen (cont. the discussion from #clojure-spec): would you like a patch to clojurescript that brings specs.clj from clojure?

No yet, just file a ticket if it doesn't exist

@dnolen here is the JIRA ticket http://dev.clojure.org/jira/browse/CLJS-1813

@dnolen It was kind of a half-cocked question. I am looking at the code along the path where i use lein cljsbuild auto. I think I am just a little mixed up due to reading through the code quickly. I am going to spend more time to make sense of it, but I am curious. Since you mentioned there is a how/why for use of dynamic bindings, could you elaborate on that a little?

It comes from my experience so far that I have just used atoms to manage state, and I am still trying to get a feel for when it is appropriate to use dynamic bindings

I do have some materials (a number of books and I've found posts by Stuart Sierra about it). If it is arbitrary, fine.

@tomjkidd there a couple of nice things, bindings are thread local - we often bind value at the start of processing a file on thread (i.e. :parallel-build true)

I don’t have time to elaborate further - I recommend just reading the source

@dnolen will do, thank you

@tomjkidd I tend to think about bindings as “temporary hidden parameters”, it is a way how to pass parameters to functions which will be called down from you stack frame (by current thread in case of clojure)

this way you don’t need to change signatures of intermediate functions, which could be impractical

e.g. imagine a world where you had to pass *out* to every function because they might want to call println

of course you could achieve similar results with atoms or other global refs, but bindings are lightweight, explicitly thread-bound and “temporary”, they should not hold persistent app-state in a sense as atoms do, they should contain only temporary parametrizations valid for a function call at hand

@darwin Thanks, I am actually making a little diagram for myself of closure/build and that explanation is helpful.

There aren't as many earmuffs as I originally thought.