This post is about data structures, which are values, but like variables, they also contain values. Therefore they can be mutable. You can argue that a mutable data structure is an object not a value, I suppose. But it can go in the same place as a value, so it makes sense to talk about subtyping.

> Mutability is a property of variable, not of a value. [...] This has nothing to do with whether it can be reassigned (i.e. mutability).

I feel like you're using "mutable" too narrowly, as it's used colloquially in some programming languages. E.g. in JS, MDN itself talks about "reassignment"[0] and not "mutability" even though people often use "mutability" as a word to refer to the distinction between `const` and `let`. The only mention of mutability there is:

> Others may prefer `let` for non-primitives that are mutated

I.e. explicitly using `let` for mutated arrays, even if not reassigned, to make the signal mutability (which JS cannot express).

Note that you used "reassignment" which is the specific word for "mutating a binding", but the article is not referring to bindings at all.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Mutability vs immutability describe the relationship between identity and state. Mutable values retain identity when their state changes. For immutable values, getting a new state requires a new identity, and importantly, existing identities never have their states changed.

Variables can be described by types. That is, a mutable slot referencing a value can be a value itself (a reference to a reference) and we can use subtype relationships to describe it. Variables are covariant when used as inputs (i.e code reads from the variable) and contravariant when used as outputs, and invariant when used as both. You can logically supply a Box<Cat> to a vet(in Box<Animal>) routine, and supply Box<Animal> to catchAndStore(out Box<Cat>). Substitute `ref X` for `Box<X>` when using a language that can pass variables by reference.

Experimentally, at least one major programming language (Rust) places mutability into the type system.

Whether or not something belongs into a type system is ultimately determined by the type system. We can choose whether or not mutability is considered a part of a type.

> When we speak of "type of a variable", we mean this variable can only be assigned (bound to) values of certain type. This has nothing to do with whether it can be reassigned (i.e. mutability).

This is a bit too simplistic IMO. You're talking about name bindings, the article is talking more about things like interior mutability.

Rebinding a name is ... generally not a type system concern by my understanding.

A nitpick: Types are properties of expressions, not values. Type errors happen at compile time, before code runs. Values only exist at run time.

> When we speak of "type of a variable", we mean this variable can only be assigned (bound to) values of certain type. This has nothing to do with whether it can be reassigned (i.e. mutability).

This seems confused. "Mutable" or "immutable" are types like any other, like "String" or "Integer".

> Types are properties of values, not variables.

In statically typed languages, variables and expressions have a compile-time type and values have a run-time type.

> Mutability is a property of variable, not of a value.

In which languages?

In D, mutability is a property of a type. And variables and expressions have a compile-time type and values have a run-time type, so mutability is also a property of variables, expressions, and values.

(Immutability is also transitive in D, so an immutable value cannot have mutable parts, including mutable references, and a variable with an immutable type cannot contain a value or reference with any mutable parts.)

> Types are properties of values, not variables.

In computer science, specifically programming language theory, types are properties of terms (syntactic expressions). It wouldn’t be possible in general to typecheck a program before running it if you had to have a value before you could discover its type.

In C, const can also answer B, but only in non-pointer contexts.

What i dont understand is why does everything have to be so brief. Take car and cdr there is only one character difference, more character differences is a good thing not bad.

Good one, yes. It was like that in Objective-C, and in the early versions of Swift. I know you know this, but it's useful to summarize for myself:

Basically inheritance is the wrong tool for this kind of stuff. NSMutableArray inherits from NSArray, so it can be passed to anywhere NSArray is expected (upcasting).

So you design your classes and expect them to be immutable, but you can't use NSArray anywhere. Because otherwise, it'll be mutable after all. You can do a runtime check as a workaround.

(I truly believe OOP should only be taught in computer science as a relic).

Yes, that’s ObjC, any NSMutableArray is an NSArray (and an NSObject) - classes passed by reference.

Swift is completely different. Standard arrays are structures, always mutable - value types passed by value

An immutable object is a special kind of mutated object, which when mutated does what exactly?

No? "Immutable" means "not mutable", so mutability and immutability are mutually exclusive.

One of the problems with this comes if you're able to dynamically promote something that was passed to you as an "immutable" type to its actual implementation type, you can break this "contract".

I'm currently being annoyed by python's type hinting system, which has exactly this sort of hierarchy for containers, but there's nothing stopping a caller/callee from using type-narrowing to "discover" that the underlying type is actually e.g. a (mutable) list, and then modifying it without any complaints from the type checker. The only way to enforce this would be to actually convert to an immutable implementation type, involving unnecessary copying.

Not all all. It merely indicates that this is an strict logic approach to the topic.

https://commonplacefacts.com/2022/07/27/principia-mathematic...