Add problem about spacing around named modifiers

1 files changed, 2 insertions, 0 deletions

diff --git a/docs/commentary/problems.html b/docs/commentary/problems.html
index c6da5787..ff2d0b83 100644
--- a/docs/commentary/problems.html
+++ b/docs/commentary/problems.html
@@ -81,6 +81,8 @@
 <p>So it seems a bit strange to rely on it for core language features like <code><span class='Function'>/</span><span class='Modifier'>⁼</span></code>. On the other hand, this is a good fit for <code><span class='Function'>⋆</span><span class='Modifier'>⁼</span></code> since we are taking an arbitrary branch of a complex function that has many of them. I'm pretty sure it's impossible to solve the issue as stated but it might be possible to move to less hazardous constructs. Structural Under is a start.</p>
 <h3 id="group-doesnt-include-trailing-empty-groups"><a class="header" href="#group-doesnt-include-trailing-empty-groups">Group doesn't include trailing empty groups</a></h3>
 <p>A length can now be specified either in an extra element in any rank-1 component of <code><span class='Value'>𝕨</span></code>, or by overtaking, since the result's fill element is an empty group. However, it still seems like it would be pretty easy to end up with a length error when a program using Group encounters unexpected data. It's a fundamental safety-convenience tradeoff, though, because specifying a length has to take more code in the general case.</p>
+<h3 id="named-modifiers-use-way-more-space-than-primitive-ones"><a class="header" href="#named-modifiers-use-way-more-space-than-primitive-ones">Named modifiers use way more space than primitive ones</a></h3>
+<p><code><span class='Function'>F</span> <span class='Modifier2'>_m_</span> <span class='Function'>G</span></code> versus <code><span class='Function'>F</span><span class='Modifier2'>∘</span><span class='Function'>G</span></code>: the syntax is the same but these don't feel the same at all. This is the worst case, as with primitive operands, <code><span class='Function'>+</span><span class='Modifier2'>_m_</span><span class='Function'>÷</span></code> isn't as far from <code><span class='Function'>+</span><span class='Modifier2'>∘</span><span class='Function'>÷</span></code>. It means a style-conscious programmer has to adjust the way they write code depending on whether things are named, and makes named modifiers feel less integrated into the language. A mix of named modifiers with primitive modifiers or trains can also look inconsistent.</p>
 <h3 id="prefixessuffixes-add-depth-and-windows-doesnt"><a class="header" href="#prefixessuffixes-add-depth-and-windows-doesnt">Prefixes/Suffixes add depth and Windows doesn't</a></h3>
 <p>It's an awkward inconsistency. Prefixes and Suffixes have to have a nested result, but Windows doesn't have to be flat; it's just that making it nested ignores the fact that it does have an array structure.</p>
 <h3 id="deshape-and-reshape-cant-ignore-trailing-axes"><a class="header" href="#deshape-and-reshape-cant-ignore-trailing-axes">Deshape and Reshape can't ignore trailing axes</a></h3>