Question

I understand that they're different since one works for setting *compile-path* and one doesn't. However, I need help with why they're different.

let creates a new scope with the given bindings, but binding...?

Was it helpful?

Solution

let creates a lexically scoped immutable alias for some value. binding creates a dynamically scoped binding for some Var.

Dynamic binding means that the code inside your binding form and any code which that code calls (even if not in the local lexical scope) will see the new binding.

Given:

user> (def ^:dynamic x 0)
#'user/x

binding actually creates a dynamic binding for a Var but let only shadows the var with a local alias:

user> (binding [x 1] (var-get #'x))
1
user> (let [x 1] (var-get #'x))
0

binding can use qualified names (since it operates on Vars) and let can't:

user> (binding [user/x 1] (var-get #'x))
1
user> (let [user/x 1] (var-get #'x))
; Evaluation aborted.
;; Can't let qualified name: user/x

let-introduced bindings are not mutable. binding-introduced bindings are thread-locally mutable:

user> (binding [x 1] (set! x 2) x)
2
user> (let [x 1] (set! x 2) x)
; Evaluation aborted.
;; Invalid assignment target

Lexical vs. dynamic binding:

user> (defn foo [] (println x))
#'user/foo
user> (binding [x 1] (foo))
1
nil
user> (let [x 1] (foo))
0
nil

See also Vars, let.

OTHER TIPS

One more syntactic difference for let vs binding:

For binding, all the initial values are evaluated before any of them are bound to the vars. This is different from let, where you can use the value of a previous "alias" in a subsequent definition.

user=>(let [x 1 y (+ x 1)] (println y))
2
nil

user=>(def y 0)
user=>(binding [x 1 y (+ x 1)] (println y))
1
nil

binding binds a value to a name in the per-thread global environment

As you mentioned, let creates a new scope for said bindings.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top