Editing

2 files changed, 5 insertions, 5 deletions

diff --git a/docs/doc/arrayrepr.html b/docs/doc/arrayrepr.html
index 43c0ad51..0e59315a 100644
--- a/docs/doc/arrayrepr.html
+++ b/docs/doc/arrayrepr.html
@@ -203,16 +203,16 @@
 <p>Strand notation is mainly useful for simple elements that don't require parentheses. A strand with one set of parentheses is no shorter than using list notation (but could look nicer), and one with more parentheses will be longer.</p>
 <h4 id="why-not-whitespace"><a class="header" href="#why-not-whitespace">Why not whitespace?</a></h4>
 <p>In APL two or more arrays that are next to each other in the code are combined into a list, a convention known as <a href="https://aplwiki.com/wiki/Strand_notation">stranding</a>. So <code><span class='Number'>2</span> <span class='Number'>3</span> <span class='Number'>5</span> <span class='Function'>+</span> <span class='Number'>1</span></code> adds a list to a number. This looks substantially cleaner than a BQN list, so it's reasonable to ask: why give it up? I admit I've been jealous of that clean look at times. But I'm also finding I view it with a certain unease: what's hiding in that space?</p>
-<p>This feeling comes because the language is doing something I didn't ask it to, and it's justified. Consider the BQN expression <code><span class='Value'>a</span> <span class='Function'>+</span><span class='Modifier'>˝</span><span class='Modifier2'>∘</span><span class='Function'>×</span><span class='Modifier2'>⎉</span><span class='Number'>1</span><span class='Ligature'>‿</span><span class='Number'>∞</span> <span class='Value'>b</span></code> for a matrix product. If we remove the space then we have <code><span class='Value'>…</span><span class='Modifier2'>⎉</span><span class='Number'>1</span> <span class='Number'>∞</span> <span class='Value'>b</span></code>. There's no good rule to say which of the three subjects <code><span class='Number'>1</span></code>, <code><span class='Number'>∞</span></code>, and <code><span class='Value'>b</span></code> to strand together. For modifiers like Rank and <a href="depth.html#the-depth-modifier">Depth</a> we'd like stranding to bind more tightly than modifier application, but in order to actually use arguments for these modifiers the modifier application should take precedence. Similar but simpler cases show up more often when binding an argument to a function. The difference between the following two statements is obvious in BQN, but with space-for-stranding one of them would require a complicating parenthesis.</p>
+<p>This feeling comes because the language is doing something I didn't ask it to, and it's well justified. Consider the BQN expression <code><span class='Value'>a</span> <span class='Function'>+</span><span class='Modifier'>˝</span><span class='Modifier2'>∘</span><span class='Function'>×</span><span class='Modifier2'>⎉</span><span class='Number'>1</span><span class='Ligature'>‿</span><span class='Number'>∞</span> <span class='Value'>b</span></code> for a matrix product. If we remove the space then we have <code><span class='Value'>…</span><span class='Modifier2'>⎉</span><span class='Number'>1</span> <span class='Number'>∞</span> <span class='Value'>b</span></code>. There's no good rule to say which of the three subjects <code><span class='Number'>1</span></code>, <code><span class='Number'>∞</span></code>, and <code><span class='Value'>b</span></code> to strand together. For modifiers like Rank and <a href="depth.html#the-depth-modifier">Depth</a> we'd like stranding to bind more tightly than modifier application, but in order to actually use arguments for these modifiers the modifier application should take precedence. Similar but simpler cases show up more often when binding an argument to a function. The difference between the following two statements is obvious in BQN, but with space-for-stranding one of them would require a complicating parenthesis.</p>
 <a class="replLink" title="Open in the REPL" target="_blank" href="https://mlochbaum.github.io/BQN/try.html#code=MyAx4oq4K+KKuMOXIDUKCjPigL8x4oq4K+KKuMOXIDU=">↗️</a><pre>    <span class='Number'>3</span> <span class='Number'>1</span><span class='Modifier2'>⊸</span><span class='Function'>+</span><span class='Modifier2'>⊸</span><span class='Function'>×</span> <span class='Number'>5</span>
 20
 
     <span class='Number'>3</span><span class='Ligature'>‿</span><span class='Number'>1</span><span class='Modifier2'>⊸</span><span class='Function'>+</span><span class='Modifier2'>⊸</span><span class='Function'>×</span> <span class='Number'>5</span>
 ⟨ 40 30 ⟩
 </pre>
-<p>Explicit stranding is also more general, because it applies equally to elements of any role. <code><span class='Number'>2</span><span class='Ligature'>‿</span><span class='Function'>+</span><span class='Ligature'>‿</span><span class='Number'>3</span></code> is a perfectly fine list in BQN—maybe it's part of an AST—while <code><span class='Number'>2</span> <span class='Function'>+</span> <span class='Number'>3</span></code> is clearly not a list. J and K restrict their stranding even further, to numbers only. It does mean that issues with stranding show up in fewer cases, but it also means that changing one element of a list from a constant to a variable requires rewriting the whole list.</p>
-<p>Why can't the more explicit list notation <code><span class='Bracket'>⟨</span><span class='Value'>a</span><span class='Separator'>,</span><span class='Value'>b</span><span class='Separator'>,</span><span class='Value'>c</span><span class='Bracket'>⟩</span></code> drop the separators? This is also largely for reasons of generality, which is even more important given that <code><span class='Bracket'>⟨⟩</span></code> is the more general-purpose list notation. Writing <code><span class='Bracket'>⟨</span><span class='Function'>÷</span><span class='Separator'>,</span><span class='Function'>-</span><span class='Separator'>,</span><span class='Number'>4</span><span class='Bracket'>⟩</span></code> without the <code><span class='Separator'>,</span></code> won't go well. For something like <code><span class='Bracket'>⟨</span><span class='Number'>2</span><span class='Function'>×</span><span class='Value'>c</span><span class='Separator'>,</span><span class='Value'>b</span><span class='Function'>-</span><span class='Number'>1</span><span class='Bracket'>⟩</span></code>, maybe the interpreter could sort it out but it would be pretty confusing. Pretty soon you're going through the list character by character trying to figure out which space is actually a separator. And cursing, probably.</p>
-<p>Fortunately, I find that after a reasonable period of adjustment typing ligatures instead of spaces doesn't feel strange, and reading code is improved overall by the more explicit notation. A minor note is that lists of literal numbers, where APL-style stranding is best, tend to show up more in the snippets that beginners write to test out the language than in programs even in the tens of lines. So this issue sticks out in first experiences with BQN, but will probably come up less later on.</p>
+<p>Explicit stranding is also more general, because it applies equally to elements of any role. <code><span class='Number'>2</span><span class='Ligature'>‿</span><span class='Function'>+</span><span class='Ligature'>‿</span><span class='Number'>3</span></code> is a perfectly fine list in BQN—maybe it's part of an AST—while <code><span class='Number'>2</span> <span class='Function'>+</span> <span class='Number'>3</span></code> is clearly not a list. Meanwhile J and K restrict their stranding even further, to numbers only. It does mean that issues with stranding show up in fewer cases, but it also means that changing one element of a list from a constant to a variable requires rewriting the whole list.</p>
+<p>Why couldn't the more explicit list notation <code><span class='Bracket'>⟨</span><span class='Value'>a</span><span class='Separator'>,</span><span class='Value'>b</span><span class='Separator'>,</span><span class='Value'>c</span><span class='Bracket'>⟩</span></code> drop the separators? This is also largely for reasons of generality—even more important here since <code><span class='Bracket'>⟨⟩</span></code> is the more general-purpose list notation. Writing <code><span class='Bracket'>⟨</span><span class='Function'>÷</span><span class='Separator'>,</span><span class='Function'>-</span><span class='Separator'>,</span><span class='Number'>4</span><span class='Bracket'>⟩</span></code> without the <code><span class='Separator'>,</span></code> won't go well. For something like <code><span class='Bracket'>⟨</span><span class='Number'>2</span><span class='Function'>×</span><span class='Value'>c</span><span class='Separator'>,</span><span class='Value'>b</span><span class='Function'>-</span><span class='Number'>1</span><span class='Bracket'>⟩</span></code>, maybe the interpreter could sort it out but it would be pretty confusing. Pretty soon you're going through the list character by character trying to figure out which space is actually a separator. And cursing, probably.</p>
+<p>Fortunately, I find that after a reasonable period of adjustment typing ligatures instead of spaces doesn't feel strange, and reading code is improved overall by the more explicit notation. A minor note is that lists of literal numbers, where APL-style stranding is best, tend to show up more in the snippets that beginners write to test out the language than in programs even in the tens of lines. So this issue sticks out in first experiences with BQN, but will come up less later on.</p>
 <h3 id="array-notation"><a class="header" href="#array-notation">Array notation?</a></h3>
 <p>BQN has literal notation for lists only right now. To get an array with rank other than 1, either <a href="reshape.html">reshape</a> a list, or <a href="couple.html#merge-and-array-theory">merge</a> a list of arrays:</p>
 <a class="replLink" title="Open in the REPL" target="_blank" href="https://mlochbaum.github.io/BQN/try.html#code=4oiY4oC/MiDipYog4p+oMiwzLCA0LDEsIDAsNeKfqQoKPiDin6gy4oC/MywgNOKAvzEsIDDigL814p+p">↗️</a><pre>    <span class='Modifier2'>∘</span><span class='Ligature'>‿</span><span class='Number'>2</span> <span class='Function'>⥊</span> <span class='Bracket'>⟨</span><span class='Number'>2</span><span class='Separator'>,</span><span class='Number'>3</span><span class='Separator'>,</span> <span class='Number'>4</span><span class='Separator'>,</span><span class='Number'>1</span><span class='Separator'>,</span> <span class='Number'>0</span><span class='Separator'>,</span><span class='Number'>5</span><span class='Bracket'>⟩</span>
diff --git a/docs/implementation/codfns.html b/docs/implementation/codfns.html
index 65ac1391..ba71fb26 100644
--- a/docs/implementation/codfns.html
+++ b/docs/implementation/codfns.html
@@ -28,7 +28,7 @@
 <p>The sort of static guarantee I want is not really a type system but an <em>axis</em> system. That is, if I take <code><span class='Value'>a</span><span class='Function'>∧</span><span class='Value'>b</span></code> I want to know that the arithmetic mapping makes sense because the two variables use the same axis. And I want to know that if <code><span class='Value'>a</span></code> and <code><span class='Value'>b</span></code> are compatible, then so are <code><span class='Value'>i</span><span class='Function'>⊏</span><span class='Value'>a</span></code> and <code><span class='Value'>i</span><span class='Function'>⊏</span><span class='Value'>b</span></code>, but not <code><span class='Value'>a</span></code> and <code><span class='Value'>i</span><span class='Function'>⊏</span><span class='Value'>b</span></code>. I could use a form of <a href="https://en.wikipedia.org/wiki/Hungarian_notation">Hungarian notation</a> for this, and write <code><span class='Value'>ia</span><span class='Gets'>←</span><span class='Value'>i</span><span class='Function'>⊏</span><span class='Value'>a</span></code> and <code><span class='Value'>ib</span><span class='Gets'>←</span><span class='Value'>i</span><span class='Function'>⊏</span><span class='Value'>b</span></code>, but it's inconvenient to rewrite the axis every time the variable appears, and I'd much prefer a computer checking agreement rather than my own fallible self.</p>
 <h3 id="performance"><a class="header" href="#performance">Performance</a></h3>
 <p>In his Co-dfns paper Aaron compares to nanopass implementations of his compiler passes. Running on the CPU and using Chez Scheme (not Racket, which is also presented) for nanopass, he finds Co-dfns is up to <strong>10 times faster</strong> for large programs. The GPU is of course slower for small programs and faster for larger ones, breaking even above 100,000 AST nodes—quite a large program. I think comparing the self-hosted BQN compiler to the one in dzaima/BQN shows that this large improvement is caused as much by nanopass being slow as Co-dfns being fast.</p>
-<p>The self-hosted compiler running in CBQN reachej full performance at about 1KB of dense source code. On large files it achieves speeds around 3MB/s, about <strong>two-thirds as fast</strong> as dzaima/BQN's compiler. This compiler was written in Java by dzaima in a much shorter time than the self-hosted compiler, and is equivalent for benchmarking purposes. While there are minor differences in syntax accepted and the exact bytecode output, I'm sure that either compiler could be modified to match the other with negligible changes in compilation time. The Java compiler is written with performance in mind, but dzaima has expended only a moderate amount of effort to optimize it.</p>
+<p>The self-hosted compiler running in CBQN reaches full performance at about 1KB of dense source code. On large files it achieves speeds around 3MB/s, about <strong>two-thirds as fast</strong> as dzaima/BQN's compiler. This compiler was written in Java by dzaima in a much shorter time than the self-hosted compiler, and is equivalent for benchmarking purposes. While there are minor differences in syntax accepted and the exact bytecode output, I'm sure that either compiler could be modified to match the other with negligible changes in compilation time. The Java compiler is written with performance in mind, but dzaima has expended only a moderate amount of effort to optimize it.</p>
 <p>A few factors other than the speed of the nanopass compiler might partly cause the discrepancy, or otherwise be worth taking into account. I doubt that these can add up to a factor of 15, so I think that nanopass is simply not as fast as more typical imperative compiler methods.</p>
 <ul>
 <li>The CBQN runtime is still suboptimal, missing SIMD implementations for some primitives used in the compiler. But improvements will be limited for operations like selection that don't vectorize as well. My estimate is a little less than a factor of 2 improvement remaining from improving speed to match Dyalog, and I think more than a factor of 4 is unlikely.</li>