aboutsummaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorMarshall Lochbaum <mwlochbaum@gmail.com>2021-12-12 11:29:59 -0500
committerMarshall Lochbaum <mwlochbaum@gmail.com>2021-12-12 11:29:59 -0500
commit4a6ad25256f4512573a87fe6f1a54fbabc86c2f6 (patch)
treec7131019c36f3800d7f5ee0b60081d0d8d453fff /docs
parent27c5057cc5b09f29f0a5962f5ba837b217b5ecb0 (diff)
Some links to the section on mutability
Diffstat (limited to 'docs')
-rw-r--r--docs/doc/match.html2
-rw-r--r--docs/doc/paradigms.html2
-rw-r--r--docs/doc/types.html2
3 files changed, 3 insertions, 3 deletions
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>