Immutability explanation

I already also have seen this “fancy” explanation for whats going on inside the box, aka the private API of Elixir, but this doesn’t change how the public behavior of variable is seen… It have changed, and anything that can change its not immutable.

… and if we’re talking guarantees, the one guarantee that this gives you is hard to find, hard to fix bugs :slight_smile:.

And in concurrent scenarios this can even get worse, as variables might be mutated even from places not visible from the current context, but seemingly unrelated places of code…

1 Like

but this doesn’t change how the public behavior of variable is seen… It have changed, and anything that can change its not immutable.

This make little sense. Which public behaviour are you talking about ?

I think you don’t really understand the concept of immutability. Immutability applies to values, not variables.

a = 1
a = 2

Yes I understand:

Screenshot from 2019-12-23 11-46-56

And we are discussing variables, thus they don’t fit in the definition of immutable, but every time this subjects of variables in Elixir not being immutable is brought to light by a newcomer, the community always change to the concept of the value stored in memory, that in fact is immutable, and I never said it wasn’t, but the variable it’s mutable.

Variable name != variable. Simplest example form the English language:

Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo

Even though these entries has the same “name” (are homonyms) each of them has different “binding” (meaning). By making variable name and variable itself the same you simplify things a lot. You can think about Elixir bindings in the same way you think about C preprocessor #define, let in Rust, let … in/where in Haskell. Wikipedia also states difference between these two terms.

1 Like
a = 1
a = 2

Those a are not the same variable, technically speaking, in Elixir. I agree we use shortcuts when speaking about things, and that it could be confusing.

Glad you agree that values are immutables, that is all what matters. You are free to reuse variable names as much as you want. Note that it may not be a good idea, and sometimes even in Elixir I keep on using thing1, thing2, etc, to have cleaner code.

1 Like

Elixir doesn’t have variables, it has bindings.

A variable’s memory can be changed.

A binding has no memory, it’s technically just a name for an expression, though in impure languages like Erlang and Elixir the runtime ensures external actions happen only once per binding’s existence.

Ruby is actually a good language to show all possible combinations (copied from above):

array = []        # variable (with rebinding) and mutable array (value)
ARRAY = []        # constant (single assignment) and mutable array (value)
array = [].freeze # variable (with rebinding) and immutable array (value)
ARRAY = [].freeze # constant (single assignment) and immutable array (value)

It shows how rebinding and mutability are two distinct things and trying to lump them together will only cause more confusion.

5 Likes

To be honest I believe the term “variable” was first misappropriated by FORTRAN (and then ALGOL) to reference a region of memory that can be changed. The original mathematical and lambda calculus meanings are closer to Elixir’s variables, imo.

2 Likes

Elixir has variables, https://elixir-lang.org/getting-started/pattern-matching.html, and I have come to the conclusion that it’s a matter of interpretation, Elixir has immutability only with regards to lexical scoping, it helps in concurrency.

In Elixir, a variable identifier is mutable, but the value it holds is immutable.

In JavaScript, const makes a variable identifier immutable, but its value is still mutable.

const foo = {};
foo = { reassign: 'me' }; // fails
foo.mutate = 'me';        // succeeds

In computer science, variable refers to its value (see Wikipedia). Therefore, Elixir variables are immutable.

Hope you like my fancy explanation!

5 Likes

Not sure about that, the VM does not provide a way to mutate values afaik, immutability is also enforced at the implementation level, not only because of lexical scoping rules.