[joncampbelldev]

I think there may be some confusion here, immutability is about the stability of values (e.g. I have a string, list, map etc and I want to pass it to others, view its value, make changes without affecting the original value).

Immutability is not the same as rebinding a name (in clojure at least) e.g. the following is perfectly valid (global and local binding of the same name repeatedly)

  (def a 1)
  (def a 2)
  (def a 3)
  (println a)
  => 3

  (let [a 4
        a 5
        a 6]
     (println a))
  => 6

[frobozz]

I see. When I see "immutable", I think of Prolog and Erlang (e.g. once X is 6, X can't be matched to 5 in the same scope) rather than languages that simply prefer byval over byref.

[joncampbelldev]

well clojure does pass by reference, but the reference is to something that cannot be changed (i.e. a persistent data structure)

[kqr]

Unification and assignment are very different concepts, though, with only fleeting similarity in some cases.

[lightbyte]

Mildly off-topic: automatically shadowing bindings is one of my favorite changes elixir made to erlang

[junke]

Some languages have immutable bindings too, where you only shadow previous bindings.

[joncampbelldev]

If you can shadow previous bindings then that would also cause no problem for repl re-usage, unless the shadowing syntax is different to the binding syntax.

Either way, unrelated to the point in the article about the advantage of immutable values for repl, not immutable bindings.

I would certainly agree that truly immutable bindings would be at best quite a stumbling block for repls, but so far no one was advocating for them as a good repl feature.

[dllthomas]

> so far no one was advocating for them as a good repl feature

GHCi has this feature, if you explicitly turn it on (-fwarn-name-shadowning with -Werror). I agree that it's not a terribly useful way to run a REPL.

[kazinator]

For a global def to be a "rebinding" rather than assignment is crippling. It means that previous references to a still see the old thing, which is wrong if you want them to see the new thing.

[kqr]

If you want others to see the new thing automatically, you need something much more powerful than plain old assignment anyway: something which will let you pick a synchronization strategy.

"Changes at any arbitrary time, including when you are halfway through reading it" is not in any way a sound synchronization strategy and the only thing you get with assignment.

You seem to understand the important difference between identity (what you see when you read an object) and reference (what you use to access the object). Next important thing on the list is how "reference" cannot just be a pointer to a place in memory -- unless it is immutable.

[kazinator]

> you need something much more powerful than plain old assignment anyway: something which will let you pick a synchronization strategy.

Right, just like the king's subjects don't actually need a toaster, but rather breakfast food cooker.

[didibus]

Clojure does not rebind the reference, it just changes it to point to something else. So it does not suffer from what you describe. Previous references will see the new thing as you'd hope.

So def on an existing binding does assignment. That's what is meant by "re-binding".

[valw]

Indeed, by immutability I really meant immutability of the values, but not of the name bindings. So I would say an optimal setup is to have a mutable execution environment which handles immutable values.