ECMAScript Primitives: Immutability vs Value Type

Question

Coming from languages like C++, Java or PHP I've learned that there are Value Types and Reference Types. Value Types store values directly in the variable (in a box / memory location). Whereas Reference Types store a reference to an Object in memory.

This makes perfect sense and seems like a simple mental model to deal with.

About primitives in JavaScript, MDN has following to say:

All primitives are immutable; that is, they cannot be altered. It is important not to confuse a primitive itself with a variable assigned a primitive value. The variable may be reassigned to a new value, but the existing value can not be changed in the ways that objects, arrays, and functions can be altered. The language does not offer utilities to mutate primitive values.

While this is undoubtedly true, why do you have to emphasize immutability when it basically comes for free implicitly? You could just say that primitives are stored directly in a variable. Such a value could never take any effect on other variables. No need to even mention it.

My guess is, that the spec wants to explicitly allow references to immutable objects (like in Python).

So my question is:

Why does the specification refer to immutable values rather than just saying "the value gets stored directly in the variable" (aka value type)?

Is it just to ensure that engine developers can implement it however they like? Or is it indeed just a very basic explanation that each variable is assigned to a value without being explicit about how this is technically implemented - but therefore you at least need the value to be immutable?

Answer 1

ECMAScript is specified at a higher level than languages like C++, giving more implementation freedom as long as it conforms to the required semantics.

For example, ECMAScript does not specify whether values are stored on heap or stack and whether they are stored as pointers or direct values. The implementation can choose the most appropriate strategy, and may even change strategy at runtime.

Mutability is significant because it affects what strategy is appropriate. For an immutable value, there is no observable difference between copying a pointer to the value or copying the value, so the implementation may choose a strategy based on performance. For mutable values, however, the implementation is basically required to use pointers when assigning, since changes to a mutable value should be observable through all variables the value is assigned to.

For an object which is ostensibly mutable, but not actually mutated during the course of the code, the engine might store it as value rather than pointer, but have a fallback strategy in case the object is mutated.

Modern JavaScript implementation use very sophisticated optimizations, where code is profiled at runtime, and "hot" areas recompiled to more optimized code based on statistics. This could easily mean a temporary variable was entirely eliminated and a short-lived value purely lived in a register. An implementation requirement that variables should be stored in memory in a certain form would prevent such optimization.

So in short, ECMAScript does not specify such implementation details, since it would put unnecessary constraints on the implementation.

Answer 2

"You could just say that primitives are stored directly in a variable. Such a value could never take any effect on other variables"

That's not true. This is where the metaphor that describes a variable as a little box that stores values breaks down. Speaking in general terms (that is, the following is not specific to a particular language), variables are abstractions. Under the hood, the actual value resides somewhere in memory, and during execution of various low level instructions, at certain points registers or other memory locations contain values that represent offsets to that address, or store the address itself, etc. The process might involve a whole bunch of copying of values back and forth, to and from temporary locations, operating on these temporary values, and so on - this whole intricate dance that helps maintain the illusion that has been dreamt up by the designers of the higher level language. The details of this are different between languages and compilers. Variables as you know them from the source code might not exist as such in the compiled code.

But coming back to the higher-lever notion: you can have variables that are aliases. Two technically distinct named labels that refer to the same value (and thus both "see" the changes to the underlying value). That's because the value is not "in" the variable. In JavaScript, you might create an alias by creating a closure over a variable.

Note that aliases are not pointers. A pointer would be something like a variable that refers to a value (a number) that itself represents an address to a completely different memory location.

Value Types vs Reference Types

It's a little tricky because the meaning of these terms can vary to some extent across languages, and can be tied to the idiosyncrasies of each language. But roughly speaking, it is not given that a value type (or a type with value copy semantics) is immutable.

The Java/C# notion of value vs reference types does not cleanly map to how types work in C++, in that in C++ these semantics have to some extent be built by you. In C++, if you create an instance of a class, it's a value type (think of the case where you're not using new). However, you can normally mutate its state (you can change parts of it in memory, and the object itself will retain its identity and "continuity of existence", Ship of Theseus–style). If you want instances of a class to be immutable by design, you have to, well, design it that way yourself.

If the type is made immutable, you can't modify the instance - if you wanted a slightly altered version, you'd have to replace the entire instance with a different object that has the desired state. That is, you'd have to make the variable refer to a different object.

Now, in a way, the combo of {a pointer + the pointed-to instance} is a reference type (in the Java/C# sense), but the pointer itself (viewed on its own) has value semantics and is passed around by copy. As before, if the pointed-to type is immutable, you can't modify the underlying instance itself - if you want to change something about it, you have to replace it with a different object, and change the value of the pointer (change what the value refers to).

Immutable primitive types are conceptually unchangeable in the same sense. E.g., consider an integer: under "normal" circumstances, you don't mutate parts of an integer value in place (furthermore, conceptually, it doesn't even have parts). You just make the variable refer to some other integer. Now, in reality, an integer is typically a multi-byte value; C++ allows you to bypass the primitive abstraction, and fiddle with the underlying bytes in place. JavaScript does not ("The language does not offer utilities to mutate primitive values"). You can fiddle with the bits, but it results in a modified copy.

And the fact that something is immutable by design also allows compilers/interpreters to assign the same underling value to different variables under various circumstances (e.g. in a type system where strings are immutable, two unrelated string variables that happen to have the same content might refer to the same underlying memory, precisely because the content can't be changed). Again, coming back to the initial point, the value is not literally "in the variable".