Mutable State

State is Mutable if it can be changed by actions. Compare ImmutableState? and ReadOnly?: ImmutableState? cannot be changed by any actions, and you can correctly assume it will remain the same. ImmutableState? is necessarily ReadOnly?. ReadOnly? state cannot be changed by your actions. However, you cannot assume that ReadOnly? state is ImmutableState? because state that is ReadOnly? to you might still be changed by someone else.

Also note that StateIsNotValue?. State is physical. Values are not physical, and cannot be physically manipulated. A given state may represent a value -- this requires a means of interpreting said state and giving it higher semantic meaning. (In most computing languages, the value is implicit in the representation. On CPUs, the value is implicit in its use. One means of interpreting state is called a 'codec', allowing representation to be cleanly separated from value.) Changing MutableState can make it represent a different value, or can make it represent the same value in a different way.

The act of changing mutable state to contain a particular value is generally called 'writing' to it. Similarly, the act of comprehending a value from a state via a known representation is generally called 'reading' from it. It's important to understand that it is the values that are written and read, not the underlying representations -- it is normal for values to go through representational transformations in this process. However, reading and writing are both physical processes and must be performed by physical things, so while the value is read or written, it continues to only ever be referenced by a physical representation.

MutableState is ConsideredHarmful by some. Its use is not particularly dangerous when there is only one reader and writer, but in non-trivial computational systems, where more than one exists, assumptions made for convenient computation may be violated. The two main solutions for this are synchronization (through either mutual exclusion or tracking transactions) or through avoidance of MutableState (by only ever writing to new spaces, and freeing space when it is provable that nobody needs it). The latter is the approach chosen by FunctionalLanguages. This advantages these languages considerably in avoidance of unnecessary synchronization. However, such languages are incomplete because they cannot describe even their own computation because they cannot describe communication -- reading, writing, and value representation. (They may, however, describe a description of computation or communications.)

Computation, itself, requires MutableState because computation is the process of calculation (performing transformations over values) as carried out in a physical world -- values need representations, and physical transformations must occur over state in order to properly reflect the useful transformations over the values that said state represents. Thus, at the very least, physical or wave-form states must be mutated within the processing unit.

While it is impossible to entirely KillMutableState, it is possible to divorce the programmer from it or to discourage its use and make such far more explicit, reducing the need for synchronization. It is proposed that the next KillerOperatingSystem and LanguageOfTheFuture be as Functional as possible.