What's the difference between variable binding and assignment?

As I understand it (read it with scepticism), in case of Elixir:

1. binding would be an expression, assignment is statement.
2. In Elixir = is basically a pattern matching with binding(?)
3. Since BEAM has only immutable values, binding making much more sense. Maybe I’m simplifying a lot - assignment assigns some literal (textual representation) to a place in memory, so changing variable X changes data in memory it was pointing to. In case of binding changing X changes only it’s pointer (so it points to another place in memory and does not affect original data it was pointing to)

Hope I did not write some non sense

A couple clarifications:

There is no “assignment” in Elixir[1], when you use ‘=’ you are doing a pattern match and it either succeeds or fails. If it fails, the current process crashes.

The compiler/runtime has a set of rules that it uses to attempt to make the pattern match succeed. One of these is “binding” and “re-binding”. Binding creates a variable that references a term in memory, if that variable does not already exist in the current scope. In Erlang, all further uses of that variable in it’s current scope are fixed to that term in memory. Elixir cheats a bit and allows you to “re-bind”[2] a variable to a new term in memory in certain situations, however the actual term in memory from the original binding does not change and will need to be garbage collected at some point.

[1]- Except where there is… Process Dictionary comes to mind.

[2]- If I am understanding it correctly: Under the hood the Elixir compiler actually creates a new variable name and just remembers that x is really x1 from now on.

That is precisely correct, though the name is a bit different, but yep.

You can see the Erlang Core code by running erlang output manually through the internal compiler and out to erlang to dump out the Core if you are curious how it implements anything (I should probably document how sometime…).

Great question

I’ve also wondered the same thing.

So would it be safe to say the following?

Binding has to do with giving names to things (or values) in a given well delimited context. Assignment is about storing things (or values) in some location (a variable)

From: https://cs.stackexchange.com/questions/39525/what-is-the-difference-between-assignment-valuation-and-name-binding

Seems pretty good.

I’d think the most ‘pure’ way of thinking of bindings are as unevaluated closures, so even doing just a = 4 means define a 0-arity function a in the current scope with the running environment that just returns a 4 and does nothing else, or that b = a * 64 is a 0-arity function like the above and uses the a in the current scope, calls it, takes its value and returns it multiplied by 64. In old functional design see:

let tester =
  let a = 4
  let b c = a * c
  let d e f = e * b f
  d 4 4

Is essentially just like a 0-arity function a that returns an integer, a 1-arity function b that returns an integer, a 1-arity function d that returns a 1-arity function <anonymous> that returns an integer, and the top 0-arity tester function that returns an integer. In Functional programming everything is a Function in concept.

Is there any problem in code like this?

  var1 = 123
  var1 = get_new_value(var1, :something)
  var1 = get_new_value2(var1, :something2)

The code you showed works. However, we usually try to reduce the number of single use variables. So, the “Elixir way” of writing that code is

var1 = 
  123
  |> get_new_value(:something)
  |> get_new_value(:something2)

Furthermore, if it was the last statement in a function, then we would drop the var1 like this:

def my_fun do
  # ...
  123
   |> get_new_value(:something)
   |> get_new_value(:something2)
end

The other issue with rebinding is that the name var1 may not only be bound to a new value but that the value could be an entirely different type.

var1 = 123 # this is an integer
var1 = get_new_value(var1, :something) # this could be a tuple
var1 = get_new_value2(var1, :something2) # this could be a map

… which does not help code clarity.

Also another way of looking at the pipeline operator is that it “threads” the result of the previous function into the next function (which is why in Clojure it’s called the thread first macro). In a pipeline there is the expectation that the return type of the previous function is compatible the expected parameter type of the next function - there is no expectation of the values travelling through pipe being all of the same type.

I’m not asking how to simplify that.

moreover, how’s that diffrent from?

def my_fun do
   # ...
  get_new_value(123, :something)
  |> get_new_value(:something2)
end

my question was about multithreading safety and related stuff.