Thread

1. js8 · 1789889511 · focus · HN ↗

   I feel like the explanation is overcomplicated. Types are properties of values, not variables. Mutability is a property of variable, not of a value.

   So it's kind of a categorical error. (I want to joke here that all categorical errors are just type errors in category theory.) 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).

   So you don't even need the notion of subtyping to explain this.

   Also, one could probably define variable as a monad over its type.

   1. barrkel · 1789905865 · focus · HN ↗

      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.

Unofficial Hacker News client; not affiliated with Y Combinator.