Some links to the section on mutability

6 files changed, 6 insertions, 6 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.
 
diff --git a/docs/doc/match.html b/docs/doc/match.html
index 1e73afb8..1e752f6f 100644
--- a/docs/doc/match.html
+++ b/docs/doc/match.html
@@ -55,7 +55,7 @@
 </pre>
 <p>This approach can't tell you whether two functions are mathematically different—that is, whether they ever return different results given the same arguments (this is an undecidable problem, and also gets confusing since &quot;different&quot; is included in its own definition). However, if two functions compare equal, then they will always return the same results.</p>
 <h3 id="block-equality"><a class="header" href="#block-equality">Block equality</a></h3>
-<p>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:</p>
+<p>The final point above about block instances is subtler. An instance of a block function or modifier is <a href="lexical.html#mutation">mutable</a>, meaning that its behavior can change over the course of a program. Consider the following two functions:</p>
 <a class="replLink" title="Open in the REPL" target="_blank" href="https://mlochbaum.github.io/BQN/try.html#code=RuKAv0cg4oaQIHsgYeKGkDEwIOKLhCB7YSvwnZWpfeKAv3th4oap8J2VqX0gfQoKRiA1ICAgIyBPbmUgcmVzdWx0CkcgOApGIDUgICAjIEFub3RoZXIgcmVzdWx04oCUdGhlIGRlZmluaXRpb24gb2YgaW5zYW5pdHkh">↗️</a><pre>    <span class='Function'>F</span><span class='Ligature'>‿</span><span class='Function'>G</span> <span class='Gets'>←</span> <span class='Brace'>{</span> <span class='Value'>a</span><span class='Gets'>←</span><span class='Number'>10</span> <span class='Separator'>⋄</span> <span class='Brace'>{</span><span class='Value'>a</span><span class='Function'>+</span><span class='Value'>𝕩</span><span class='Brace'>}</span><span class='Ligature'>‿</span><span class='Brace'>{</span><span class='Value'>a</span><span class='Gets'>↩</span><span class='Value'>𝕩</span><span class='Brace'>}</span> <span class='Brace'>}</span>
 ⟨ (function block) (function block) ⟩
 
diff --git a/docs/doc/paradigms.html b/docs/doc/paradigms.html
index a0305aa9..38093372 100644
--- a/docs/doc/paradigms.html
+++ b/docs/doc/paradigms.html
@@ -10,7 +10,7 @@
 <p>When programming in BQN, I almost always use array, tacit, and (slightly impure) functional styles, and encapsulate code in medium or large projects using namespaces. I sometimes use object-oriented or imperative programming in addition to these.</p>
 <h2 id="typing"><a class="header" href="#typing">Typing</a></h2>
 <p>BQN is a <strong>dynamically typed</strong> language with a coarse <a href="types.html">type system</a> 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.</p>
-<p>BQN has no &quot;pointer&quot; or &quot;reference&quot; type, and uses <strong>automatic memory management</strong>. Its data types are <strong>immutable</strong> 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.</p>
+<p>BQN has no &quot;pointer&quot; or &quot;reference&quot; type, and uses <strong>automatic memory management</strong>. Its data types are <strong>immutable</strong> while operations and namespaces are <a href="lexical.html#mutation">mutable</a>; mutable data can create reference loops, which the implementation must account for in garbage collection but the programmer doesn't have to worry about.</p>
 <p>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.</p>
 <h2 id="styles"><a class="header" href="#styles">Styles</a></h2>
 <p>BQN is designed for <strong>array</strong> programming. The array is its only built-in collection type and it has many primitives designed to work with arrays.</p>
diff --git a/docs/doc/types.html b/docs/doc/types.html
index 075a0878..20ab9578 100644
--- a/docs/doc/types.html
+++ b/docs/doc/types.html
@@ -42,7 +42,7 @@
   </g>
 </svg>
 
-<p>The reason operations and namespaces are called &quot;mutable&quot; 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 <code><span class='Gets'>↩</span></code>, 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 <code><span class='Gets'>↩</span></code> 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 <code><span class='Brace'>{</span><span class='Value'>𝕩</span><span class='Brace'>}</span></code>) creates a different one each time, so that two different instances don't <a href="match.html">match</a> (<code><span class='Function'>≡</span></code>) each other. Data values created at different times may match, but mutable values never will.</p>
+<p>The reason operations and namespaces are called &quot;mutable&quot; is that the values obtained from them—by calling an operation on particular arguments or reading a field from a namespace—<a href="lexical.html#mutation">may change</a> over the course of the program. This property is caused by variable modification <code><span class='Gets'>↩</span></code>, 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 <code><span class='Gets'>↩</span></code> 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 <code><span class='Brace'>{</span><span class='Value'>𝕩</span><span class='Brace'>}</span></code>) creates a different one each time, so that two different instances don't <a href="match.html">match</a> (<code><span class='Function'>≡</span></code>) each other. Data values created at different times may match, but mutable values never will.</p>
 <p>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 <a href="fill.html">fill element</a>), 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.</p>
 <h2 id="data-types"><a class="header" href="#data-types">Data types</a></h2>
 <p>Data types—numbers, characters, and arrays—are more like &quot;things&quot; than &quot;actions&quot;. If called as a function, a value of one of these types simply returns itself. Data can be uniquely represented, compared for equality, and ordered using BQN's <a href="order.html#array-ordering">array ordering</a>; in contrast, determining whether two functions always return the same result can be undecidable. For arrays, these properties apply only if there are no operations inside. We might say that &quot;data&quot; in BQN refers to numbers, characters, and arrays of data.</p>