> x = [1, 2, 3]
> x = 2 # the structure [1, 2, 3] still exists in memory, but now the variable x is bound to the value 2
All data is still immutable, the BEAM itself requires so. Dave Thomas explains this in its "Programming Elixir" book.
I wasn't talking about data, I was talking about variables. Yeah you just called it "re-binded". I called it "changed" or "mutated".
You have a function, and you see x=1 first and print its value. You'd see "1". Then you can have x=2 maybe a few lines or pages below, print it, you get "2". Variable x has changed its value. I even illustrated with a short example.
> All data is still immutable, the BEAM itself requires so. All data is still immutable, the BEAM itself requires so
Agreed. I don't think I ever talked about data being mutable. Having used BEAM VM for the last 5 years, yes, I noticed data is immutable ;-)
immutable/mutable data and immutable/mutable identifiers are two different things. One is not called the other, they are separate things really.
> It's not mutated or changed it points to a totally different memory location
So you said it yourself. It points to a different memory location. So how is x not mutated then? "Mutated" is a synonym for "change", or so I thought apparently.
I don't see how one can look at a variable being reassigned and say "nope, variable didn't change", where it clearly has a new value in the line below.
> Immutable data is what eliminates a large number of potential bugs.
Agreed. Was using Erlang for many years and tried Haskell before. Immutable data is pretty nice most of the time.
> care if someone reuses the name above the point in code you used it.
Wait, is it the opposite of what you were trying to say? Wouldn't you want to care if you are now randomly re-using or changing variables someone else assigned. I thought immutability was a good thing.
> By allowing rebinding you only care about the code below the place your introduced a variable.
Unfortunately in my code base, the code above the place where variables are introduced is just as mission critical as the code after the place. Maybe I am using a strange coding style or paradigm ;-)
def t() do
x=1
f=fn -> x end
x=2
f.()
end
I prefer the way Erlang does it. But I get why Elixir did what they did as well.