Corrections

1 files changed, 2 insertions, 2 deletions

diff --git a/docs/commentary/overload.html b/docs/commentary/overload.html
index 5004d34c..f45771f1 100644
--- a/docs/commentary/overload.html
+++ b/docs/commentary/overload.html
@@ -20,13 +20,13 @@
 <h2 id="equivalent-overloading"><a class="header" href="#equivalent-overloading">Equivalent overloading</a></h2>
 <p>APL isn't really a &quot;one obvious way to do it&quot; in the sense that Python is, but it does follow a principle I'd describe as &quot;one way is enough&quot;. That means that if APL already has a way to represent some data or a computation, it won't add another without a concrete benefit like shorter or faster code. This is why APL booleans are a kind of integer (I defend this decision <a href="../tutorial/combinator.html#booleans">here</a>), and why it has one array datatype instead of various kinds of collection or a separate string type.</p>
 <p>This means that something like the number 1 can mean many things, like an index or a count or a boolean, and the replicate function <code><span class='Function'>/</span></code> might mean repeating or filtering. It's overloading, but it's a very consistent form because the mathematical description of what's going on in either case is the same. But it's not the only way—some statically-typed languages like Java and Haskell prefer to declare classes to split things up, so that the type system can check things for the user. An extreme example is a system that takes user input but needs to sanitize or escape it before passing it to certain functions. The APL way would be to represent both unsafe and safe input as strings, which is obviously dangerous.</p>
-<p>However, the advantage of representing everything in a consistent format is that methods that work on one thing tend to work on many things. Want to reverse a string? It's just <code><span class='Function'>⌽</span></code>. Defining boolean negation <code><span class='Function'>¬</span><span class='Value'>𝕩</span></code> more generally as <code><span class='Number'>1</span><span class='Function'>-</span><span class='Value'>𝕩</span></code> makes some arithmetic more obvious, for example <code><span class='Function'>+</span><span class='Modifier'>´</span><span class='Function'>¬</span><span class='Value'>l</span></code> is <code><span class='Paren'>(</span><span class='Function'>≠</span><span class='Value'>l</span><span class='Paren'>)</span><span class='Function'>-+</span><span class='Modifier'>´</span><span class='Value'>l</span></code>. And connections can be made at a higher level too: if you learn a rule like <code><span class='Value'>a</span><span class='Function'>⊏</span><span class='Value'>b</span><span class='Function'>⊏</span><span class='Value'>c</span></code> ←→ <code><span class='Value'>a</span><span class='Function'>⊏</span><span class='Paren'>(</span><span class='Value'>b</span><span class='Function'>⊏</span><span class='Value'>c</span><span class='Paren'>)</span></code>, that applies for every meaning of <code><span class='Function'>⊏</span></code>. As long as <code><span class='Value'>a</span></code> and <code><span class='Value'>b</span></code> are flat arrays, that is, which highlights a conflict between this sort of compatible overloading and other sorts of extension.</p>
+<p>However, the advantage of representing everything in a consistent format is that methods that work on one thing tend to work on many things. Want to reverse a string? It's just <code><span class='Function'>⌽</span></code>. Defining boolean negation <code><span class='Function'>¬</span><span class='Value'>𝕩</span></code> more generally as <code><span class='Number'>1</span><span class='Function'>-</span><span class='Value'>𝕩</span></code> makes some arithmetic more obvious, for example <code><span class='Function'>+</span><span class='Modifier'>´</span><span class='Function'>¬</span><span class='Value'>l</span></code> is <code><span class='Paren'>(</span><span class='Function'>≠</span><span class='Value'>l</span><span class='Paren'>)</span><span class='Function'>-+</span><span class='Modifier'>´</span><span class='Value'>l</span></code>. And connections can be made at a higher level too: if you learn a rule like <code><span class='Value'>a</span><span class='Function'>⊏</span><span class='Value'>b</span><span class='Function'>⊏</span><span class='Value'>c</span></code> ←→ <code><span class='Paren'>(</span><span class='Value'>a</span><span class='Function'>⊏</span><span class='Value'>b</span><span class='Paren'>)</span><span class='Function'>⊏</span><span class='Value'>c</span></code>, that applies for every meaning of <code><span class='Function'>⊏</span></code>. As long as <code><span class='Value'>a</span></code> and <code><span class='Value'>b</span></code> are flat arrays, that is, which highlights a conflict between this sort of compatible overloading and other sorts of extension.</p>
 <h2 id="extensions"><a class="header" href="#extensions">Extensions</a></h2>
 <p>Heading further into the woods, we see that the APL family extends functions in ways that don't follow strictly from the definition. Usually this happens within a single primitive. For example, First (monadic <code><span class='Function'>⊑</span></code>) is only natural to apply to an array, since otherwise there's no first element. But it's defined to return an atom with no changes, effectively treating it as a unit array. This sort of implicit promotion is used just about everywhere it could be, since in all cases it's obvious what needs to be done and inconvenient to require explicit conversion.</p>
 <p>If that was all, it would hardly be worth mentioning. A more significant family of extensions is the <a href="../doc/depth.html#testing-depth-for-multiple-axis-primitives">use of depth</a> to allow a primitive to work on multiple axes in general but also to have a convenient one-axis form. Then there's <a href="../doc/arithmetic.html#character-arithmetic">character arithmetic</a>, allowing <code><span class='String'>'a'</span> <span class='Function'>+</span> <span class='Number'>3</span></code>. In fact, isn't array arithmetic itself a big extension?</p>
 <p>There are examples outside the array world that I find worse than anything in BQN. <code><span class='Function'>+</span></code> for string catenation. This no longer obeys commutativity or distributivity: it's not safe to rearrange <code><span class='Value'>a</span> <span class='Function'>+</span> <span class='Value'>b</span></code> to <code><span class='Value'>b</span> <span class='Function'>+</span> <span class='Value'>a</span></code> or <code><span class='Paren'>(</span><span class='Value'>a</span><span class='Function'>+</span><span class='Value'>b</span><span class='Paren'>)</span><span class='Value'>*c</span></code> to <code><span class='Paren'>(</span><span class='Value'>a*c</span><span class='Paren'>)</span><span class='Function'>+</span><span class='Paren'>(</span><span class='Value'>b*c</span><span class='Paren'>)</span></code> in languages that do this! NumPy and MATLAB allow a boolean array to be used as an index, performing filtering. This one doesn't obey the rule that the length of <code><span class='Value'>a</span><span class='Bracket'>[</span><span class='Value'>b</span><span class='Bracket'>]</span></code> is the length of <code><span class='Value'>b</span></code>, or any other length-based rules really.</p>
 <p>Sometimes what seems like an extension can be unified into a single more general primitive. For example, APL has <a href="https://aplwiki.com/wiki/Scalar_extension">scalar extension</a> to allow you to add, say, a scalar to a list in <code><span class='Number'>1</span> <span class='Function'>+</span> <span class='Number'>2</span><span class='Ligature'>‿</span><span class='Number'>3</span><span class='Ligature'>‿</span><span class='Number'>4</span></code>. J and BQN use the more general <a href="../doc/leading.html#leading-axis-agreement">leading axis agreement</a>, which has this extension as a special case (although incidentally, BQN removes some unprincipled extension of list-like functions like Reverse to rank-0 arguments). Character arithmetic can also be viewed in this way considering numbers and characters to be pairs of &quot;characterness&quot; 0 or 1, and a numeric value.</p>
-<p>I think many primitive pairs, such as <code><span class='Function'>-</span></code>, <code><span class='Function'>⋆</span></code>, <code><span class='Function'>«</span></code>, <code><span class='Function'>⥊</span></code>, and <code><span class='Function'>⍉</span></code>, fall into this category too. Primitives like can be described as a general dyadic function, and a monadic case that comes from a default left argument (sometimes dependent on the left argument: it's <code><span class='Paren'>(</span><span class='Function'>=</span><span class='Value'>𝕩</span><span class='Paren'>)</span><span class='Function'>-</span><span class='Number'>1</span></code> for <code><span class='Function'>⍉</span></code>). The primitive <code><span class='Function'>⋈</span></code> is so tight it might be considered a fully compatible overload, returning a list of all arguments. Such primitive pairs can sometimes be used ambivalently in simple ways (<code><span class='Function'>⋆</span><span class='Modifier'>⁼</span></code> is pretty nice), but more often the usefulness is just that it's easier to think about each pair as one thing rather than two. It's just two views of the same idea.</p>
+<p>I think many primitive pairs, such as <code><span class='Function'>-</span></code>, <code><span class='Function'>⋆</span></code>, <code><span class='Function'>«</span></code>, <code><span class='Function'>⥊</span></code>, and <code><span class='Function'>⍉</span></code>, fall into this category too. Primitives like can be described as a general dyadic function, and a monadic case that comes from a default left argument (sometimes dependent on the right argument: it's <code><span class='Paren'>(</span><span class='Function'>=</span><span class='Value'>𝕩</span><span class='Paren'>)</span><span class='Function'>-</span><span class='Number'>1</span></code> for <code><span class='Function'>⍉</span></code>). The primitive <code><span class='Function'>⋈</span></code> is so tight it might be considered a fully compatible overload, returning a list of all arguments. Such primitive pairs can sometimes be used ambivalently in simple ways (<code><span class='Function'>⋆</span><span class='Modifier'>⁼</span></code> is pretty nice), but more often the usefulness is just that it's easier to think about each pair as one thing rather than two. It's just two views of the same idea.</p>
 <h2 id="mnemonic-overloading"><a class="header" href="#mnemonic-overloading">Mnemonic overloading</a></h2>
 <p>Okay, we are slipping down the slope nicely, now what about the primitives where the two halves don't quite do the same thing? Take <code><span class='Function'>∾</span></code> to start smoothly. The dyadic form joins two lists and the monadic form joins a list of lists. Well, this is really one function that takes its arguments in a slightly unusual way, since dyadic <code><span class='Function'>∾</span></code> is <code><span class='Function'>∾</span><span class='Modifier2'>∘</span><span class='Function'>⋈</span></code>. The primitive <code><span class='Function'>↑</span></code> for Prefixes/Take (<code><span class='Function'>↓</span></code> too) is similar, but in a trickier way: if <code><span class='Value'>𝕨</span></code> is between <code><span class='Number'>0</span></code> and <code><span class='Function'>≠</span><span class='Value'>𝕩</span></code>, <code><span class='Value'>𝕨</span><span class='Function'>↑</span><span class='Value'>𝕩</span></code> is a prefix of <code><span class='Value'>𝕩</span></code>. Then <code><span class='Function'>↑</span></code> is the list of all these prefixes, so <code><span class='Value'>𝕨</span><span class='Function'>⊑↑</span><span class='Value'>𝕩</span></code> is <code><span class='Value'>𝕨</span><span class='Function'>↑</span><span class='Value'>𝕩</span></code>. It's almost a kind of partial application.</p>
 <p>These primitives are easier to remember in the same way that it's much easier to memorize just <code><span class='Function'>⊏</span></code> instead of a select function and a separate first-cell function. If I weren't allowed to overload them together, I probably just wouldn't include monadic <code><span class='Function'>↑↓⊏</span></code> (or <code><span class='Function'>√⋆</span></code>, even <code><span class='Function'>-</span></code>?), and maybe not even dyadic <code><span class='Function'>∾</span></code>.</p>