Finally nailed down my issue with 2-trains versus atop

2 files changed, 5 insertions, 0 deletions

diff --git a/commentary/problems.md b/commentary/problems.md
index 7e1f89d9..2753ce80 100644
--- a/commentary/problems.md
+++ b/commentary/problems.md
@@ -187,6 +187,9 @@ Select chooses whether the left argument maps to right argument axes or selects
 ### Unclear primitive names
 Blanket issue for names that I don't find informative: "Solo", "Bins", "Find", and "Group".
 
+### Modifiers look looser than trains without spaces
+Consider `⋆∘-ט`. It's just a sequence of three functions so the use of `∘` rather than `·` is to highlight structure: `⋆∘-` is more tightly bound so the suggestion is to consider this composition as a single entity. But in fact `-` is closer to `ט` than to `⋆`, intuitively suggesting the opposite. Adding a space fixes it: `⋆∘- ט` visually connects `⋆∘-`. It's unfortunate that this is something the writer must do rather than something the notation encourages.
+
 ### Tacit exports can leak data
 One of the nice facets of BQN's module system is that it provides perfect encapsulation: if you have variables `a` and `b` in a namespace (or closure) initialized so that `a≤b`, and all exported operations maintain the property that `a≤b`, then that property will always be true. Well, not quite: if you define, say `Inc ⇐ IncA ⊣ IncB` to increase the values of both `a` and `b` by `𝕩`, then `Inc` maintains `a≤b`, but `IncA` doesn't—and it can be extracted with `•Decompose`. This isn't too serious because it sounds impossible to do accidentally, and it's easy to protect against.
 
diff --git a/docs/commentary/problems.html b/docs/commentary/problems.html
index 2c7c0964..d1dd2c17 100644
--- a/docs/commentary/problems.html
+++ b/docs/commentary/problems.html
@@ -139,6 +139,8 @@
 <p>Select chooses whether the left argument maps to right argument axes or selects from the first axis only based on its depth. Without prototypes an empty array has depth 1, so it selects no major cells. However, it could also select from no axes (a no-op) and in some contexts the other behavior would be surprising.</p>
 <h3 id="unclear-primitive-names">Unclear primitive names</h3>
 <p>Blanket issue for names that I don't find informative: &quot;Solo&quot;, &quot;Bins&quot;, &quot;Find&quot;, and &quot;Group&quot;.</p>
+<h3 id="modifiers-look-looser-than-trains-without-spaces">Modifiers look looser than trains without spaces</h3>
+<p>Consider <code><span class='Function'>⋆</span><span class='Modifier2'>∘</span><span class='Function'>-×</span><span class='Modifier'>˜</span></code>. It's just a sequence of three functions so the use of <code><span class='Modifier2'>∘</span></code> rather than <code><span class='Nothing'>·</span></code> is to highlight structure: <code><span class='Function'>⋆</span><span class='Modifier2'>∘</span><span class='Function'>-</span></code> is more tightly bound so the suggestion is to consider this composition as a single entity. But in fact <code><span class='Function'>-</span></code> is closer to <code><span class='Function'>×</span><span class='Modifier'>˜</span></code> than to <code><span class='Function'>⋆</span></code>, intuitively suggesting the opposite. Adding a space fixes it: <code><span class='Function'>⋆</span><span class='Modifier2'>∘</span><span class='Function'>-</span> <span class='Function'>×</span><span class='Modifier'>˜</span></code> visually connects <code><span class='Function'>⋆</span><span class='Modifier2'>∘</span><span class='Function'>-</span></code>. It's unfortunate that this is something the writer must do rather than something the notation encourages.</p>
 <h3 id="tacit-exports-can-leak-data">Tacit exports can leak data</h3>
 <p>One of the nice facets of BQN's module system is that it provides perfect encapsulation: if you have variables <code><span class='Value'>a</span></code> and <code><span class='Value'>b</span></code> in a namespace (or closure) initialized so that <code><span class='Value'>a</span><span class='Function'>≤</span><span class='Value'>b</span></code>, and all exported operations maintain the property that <code><span class='Value'>a</span><span class='Function'>≤</span><span class='Value'>b</span></code>, then that property will always be true. Well, not quite: if you define, say <code><span class='Function'>Inc</span> <span class='Gets'>⇐</span> <span class='Function'>IncA</span> <span class='Function'>⊣</span> <span class='Function'>IncB</span></code> to increase the values of both <code><span class='Value'>a</span></code> and <code><span class='Value'>b</span></code> by <code><span class='Value'>𝕩</span></code>, then <code><span class='Function'>Inc</span></code> maintains <code><span class='Value'>a</span><span class='Function'>≤</span><span class='Value'>b</span></code>, but <code><span class='Function'>IncA</span></code> doesn't—and it can be extracted with <code><span class='Function'>•Decompose</span></code>. This isn't too serious because it sounds impossible to do accidentally, and it's easy to protect against.</p>
 <h3 id="strands-go-left-to-right">Strands go left to right</h3>