Some links to the section on mutability

3 files changed, 3 insertions, 3 deletions

diff --git a/doc/match.md b/doc/match.md
index 14ff8ffb..9d102238 100644
--- a/doc/match.md
+++ b/doc/match.md
@@ -50,7 +50,7 @@ This approach can't tell you whether two functions are mathematically different�
 
 ### Block equality
 
-The final point above about block instances is subtler. An instance of a block function or modifier is mutable, meaning that its behavior can change over the course of a program. Consider the following two functions:
+The final point above about block instances is subtler. An instance of a block function or modifier is [mutable](lexical.md#mutation), meaning that its behavior can change over the course of a program. Consider the following two functions:
 
         F‿G ← { a←10 ⋄ {a+𝕩}‿{a↩𝕩} }
 
diff --git a/doc/paradigms.md b/doc/paradigms.md
index 4a9047b6..c20cf289 100644
--- a/doc/paradigms.md
+++ b/doc/paradigms.md
@@ -12,7 +12,7 @@ When programming in BQN, I almost always use array, tacit, and (slightly impure)
 
 BQN is a **dynamically typed** language with a coarse [type system](types.md) that only distinguishes types when the difference is blindingly obvious. There is a single numeric type and a single unicode character type. A fast implementation such as CBQN will check to see when it can represent the data with a smaller type than the one offered by the language. BQN usually avoids implicit type conversion, with the exception that many primitives automatically convert atoms to unit arrays. The fact that a data value can be applied as a function to return itself could also be considered an implicit conversion.
 
-BQN has no "pointer" or "reference" type, and uses **automatic memory management**. Its data types are **immutable** while operations and namespaces are mutable; mutable data can create reference loops, which the implementation must account for in garbage collection but the programmer doesn't have to worry about.
+BQN has no "pointer" or "reference" type, and uses **automatic memory management**. Its data types are **immutable** while operations and namespaces are [mutable](lexical.md#mutation); mutable data can create reference loops, which the implementation must account for in garbage collection but the programmer doesn't have to worry about.
 
 Dynamic types and garbage collection introduce overhead relative to a statically-typed or manually managed language. The impact of this overhead can be greatly reduced with array programming, because an array of numbers or characters can be stored as a single unit of memory and processed with functions specialized to its element type.
 
diff --git a/doc/types.md b/doc/types.md
index 96870844..288fd5d0 100644
--- a/doc/types.md
+++ b/doc/types.md
@@ -44,7 +44,7 @@ FS ← {𝕩 Enc˜ "g"Attr⟨"font-size",(Fmt𝕨)∾"px"⟩}
 ⟩
 -->
 
-The reason operations and namespaces are called "mutable" is that the values obtained from them—by calling an operation on particular arguments or reading a field from a namespace—may change over the course of the program. This property is caused by variable modification `↩`, which can directly change a namespace field, or change the behavior of an operation that uses the modified variable. This means that a program that doesn't include `↩` won't have such changes in behavior. However, there will still be an observable difference between immutable data and the mutable types: code that creates a mutable value (for example, a block function `{𝕩}`) creates a different one each time, so that two different instances don't [match](match.md) (`≡`) each other. Data values created at different times may match, but mutable values never will.
+The reason operations and namespaces are called "mutable" is that the values obtained from them—by calling an operation on particular arguments or reading a field from a namespace—[may change](lexical.md#mutation) over the course of the program. This property is caused by variable modification `↩`, which can directly change a namespace field, or change the behavior of an operation that uses the modified variable. This means that a program that doesn't include `↩` won't have such changes in behavior. However, there will still be an observable difference between immutable data and the mutable types: code that creates a mutable value (for example, a block function `{𝕩}`) creates a different one each time, so that two different instances don't [match](match.md) (`≡`) each other. Data values created at different times may match, but mutable values never will.
 
 An array is considered immutable because its shape, and what elements it contains, cannot change. An array has no identity outside these properties (and possibly its [fill element](fill.md)), so an array with a different shape or different elements would simply be a different array. However, any element of an array could be mutable, in which case the behavior of the array would change with respect to the operation of selecting that element and calling it or accessing a field.