Specify function Undo headers

4 files changed, 11 insertions, 3 deletions

diff --git a/docs/spec/evaluate.html b/docs/spec/evaluate.html
index d1ab7b80..892aa7a5 100644
--- a/docs/spec/evaluate.html
+++ b/docs/spec/evaluate.html
@@ -11,7 +11,7 @@
 <p>The result of parsing a valid BQN program is a <code><span class='Function'>PROGRAM</span></code>, and the program is run by evaluating this term.</p>
 <p>A <code><span class='Function'>PROGRAM</span></code> or <code><span class='Function'>BODY</span></code> is a list of <code><span class='Function'>STMT</span></code>s, which are evaluated in program order. A result is always required for <code><span class='Function'>BODY</span></code> nodes, and sometimes for <code><span class='Function'>PROGRAM</span></code> nodes (for example, when loaded with <code><span class='Function'>•Import</span></code>). If any identifiers in the node's scope are exported, or any of its statements is an <code><span class='Function'>EXPORT</span></code>, then the result is the namespace created in order to evaluate the node. If a result is required but the namespace case doesn't apply, then the last <code><span class='Function'>STMT</span></code> node must be an <code><span class='Function'>EXPR</span></code> and its result is used. The statement <code><span class='Function'>EXPR</span></code> evaluates some APL code and possibly assigns the results, while <code><span class='Value'>nothing</span></code> evaluates any <code><span class='Value'>subject</span></code> or <code><span class='Function'>Derv</span></code> terms it contains but discards the results. An <code><span class='Function'>EXPORT</span></code> statement performs no action.</p>
 <p>A block consists of several <code><span class='Function'>BODY</span></code> terms, some of which may have an accompanying header describing accepted inputs and how they are processed. An immediate block <code><span class='Value'>brImm</span></code> can only have one <code><span class='Function'>BODY</span></code>, and is evaluated by evaluating the code in it. Other types of blocks do not evaluate any <code><span class='Function'>BODY</span></code> immediately, but instead return a function or modifier that obtains its result by evaluating a particular <code><span class='Function'>BODY</span></code>. The <code><span class='Function'>BODY</span></code> is identified and evaluated once the block has received enough inputs (operands or arguments), which for modifiers can take one or two calls: if two calls are required, then on the first call the operands are simply stored and no code is evaluated yet. Two calls are required if there is more than one <code><span class='Function'>BODY</span></code> term, if the <code><span class='Function'>BODY</span></code> contains the special names <code><span class='Value'>𝕨𝕩𝕤</span><span class='Function'>𝕎𝕏𝕊</span></code>, or if its header specifies arguments (the header-body combination is a <code><span class='Modifier'>_mCase</span></code> or <code><span class='Modifier2'>_cCase_</span></code>). Otherwise only one is required.</p>
-<p>To evaluate a block when enough inputs have been received, first the correct case must be identified. To do this, first each special case (<code><span class='Function'>FCase</span></code>, <code><span class='Modifier'>_mCase</span></code>, or <code><span class='Modifier2'>_cCase_</span></code>) is checked in order to see if its arguments are strucurally compatible with the given arguments. That is, is <code><span class='Value'>headW</span></code> is a <code><span class='Value'>subject</span></code>, there must be a left argument matching that structure, and if <code><span class='Value'>headX</span></code> is a <code><span class='Value'>subject</span></code>, the right argument must match that structure. This means that <code><span class='Value'>𝕨</span></code> not only matches any left argument but also no argument. The test for compatibility is the same as for multiple assignment described below, except that the header may contain constants, which must match the corresponding part of the given argument.If no special case matches, then an appropriate general case (<code><span class='Function'>FMain</span></code>, <code><span class='Modifier'>_mMain</span></code>, or <code><span class='Modifier2'>_cMain_</span></code>) is used: if there are two, the first is used with no left argument and the second with a left argument; if there are one, it is always used, and if there are none, an error results.</p>
+<p>To evaluate a block when enough inputs have been received, first the correct case must be identified. To do this, first each special case (<code><span class='Function'>FCase</span></code>, <code><span class='Modifier'>_mCase</span></code>, or <code><span class='Modifier2'>_cCase_</span></code>), excluding <code><span class='Function'>FCase</span></code> nodes containing <code><span class='Function'>UndoHead</span></code>, is checked in order to see if its arguments are strucurally compatible with the given arguments. That is, is <code><span class='Value'>headW</span></code> is a <code><span class='Value'>subject</span></code>, there must be a left argument matching that structure, and if <code><span class='Value'>headX</span></code> is a <code><span class='Value'>subject</span></code>, the right argument must match that structure. This means that <code><span class='Value'>𝕨</span></code> not only matches any left argument but also no argument. The test for compatibility is the same as for multiple assignment described below, except that the header may contain constants, which must match the corresponding part of the given argument.If no special case matches, then an appropriate general case (<code><span class='Function'>FMain</span></code>, <code><span class='Modifier'>_mMain</span></code>, or <code><span class='Modifier2'>_cMain_</span></code>) is used: if there are two, the first is used with no left argument and the second with a left argument; if there are one, it is always used, and if there are none, an error results.</p>
 <p>The only remaining step before evaluating the <code><span class='Function'>BODY</span></code> is to bind the inputs and other names. Special names are always bound when applicable: <code><span class='Value'>𝕨𝕩𝕤</span></code> if arguments are used, <code><span class='Value'>𝕨</span></code> if there is a left argument, <code><span class='Value'>𝕗𝕘</span></code> if operands are used, and <code><span class='Modifier'>_𝕣</span></code> and <code><span class='Modifier2'>_𝕣_</span></code> for modifiers and combinators, respectively. Any names in the header are also bound, allowing multiple assignment for arguments.</p>
 <p>If there is no left argument, but the <code><span class='Function'>BODY</span></code> contains <code><span class='Value'>𝕨</span></code> at the top level, then it is conceptually re-parsed with <code><span class='Value'>𝕨</span></code> replaced by <code><span class='Nothing'>·</span></code> to give a monadic version before application; this modifies the syntax tree by replacing some instances of <code><span class='Value'>arg</span></code> with <code><span class='Value'>nothing</span></code>. However, it also causes an error if, in a function that is called with no left argument, <code><span class='Value'>𝕨</span></code> is used as an operand or list element, where <code><span class='Value'>nothing</span></code> is not allowed by the grammar. The same effect can also be achieved dynamically by treating <code><span class='Nothing'>·</span></code> as a value and checking for it during execution. If it is used as a left argument, then the function should instead be called with no left argument (and similarly in trains); it it is used as a right argument, then the function and its left argument are evaluated but rather than calling the function <code><span class='Nothing'>·</span></code> is &quot;returned&quot; immediately; and if it is used in another context then it causes an error.</p>
 <h3 id="assignment">Assignment</h3>
diff --git a/docs/spec/grammar.html b/docs/spec/grammar.html
index dca88643..46509c05 100644
--- a/docs/spec/grammar.html
+++ b/docs/spec/grammar.html
@@ -73,9 +73,15 @@
 <span class='Function'>FuncHead</span> <span class='Function'>=</span> <span class='Value'>headW?</span> <span class='Paren'>(</span> <span class='Function'>F</span> <span class='Function'>|</span> <span class='String'>&quot;𝕊&quot;</span> <span class='Paren'>)</span> <span class='Value'>headX</span>
          <span class='Function'>|</span> <span class='Value'>sl</span> <span class='Function'>|</span> <span class='String'>&quot;(&quot;</span> <span class='Value'>subExpr</span> <span class='String'>&quot;)&quot;</span> <span class='Function'>|</span> <span class='Value'>brSub</span> <span class='Function'>|</span> <span class='Value'>list</span>   <span class='Comment'># subject,
 </span>         <span class='Function'>|</span> <span class='Function'>ANY</span> <span class='Paren'>(</span> <span class='String'>&quot;‿&quot;</span> <span class='Function'>ANY</span> <span class='Paren'>)</span><span class='Function'>+</span>                      <span class='Comment'># but not s
-</span><span class='Modifier'>_m1Head</span>  <span class='Function'>=</span> <span class='Value'>headW?</span> <span class='Function'>Mod1H1</span> <span class='Value'>headX</span>
+</span>         <span class='Function'>|</span> <span class='Function'>UndoHead</span>
+<span class='Modifier'>_m1Head</span>  <span class='Function'>=</span> <span class='Value'>headW?</span> <span class='Function'>Mod1H1</span> <span class='Value'>headX</span>
 <span class='Modifier2'>_m2Head_</span> <span class='Function'>=</span> <span class='Value'>headW?</span> <span class='Function'>Mod2H1</span> <span class='Value'>headX</span>
 </pre>
+<p>Additionally, an inference header doesn't affect evaluation of the function, but describes how an inferred property (<a href="inferred.html#undo">Undo</a>) should be computed. Here <code><span class='String'>&quot;˜&quot;</span></code> and <code><span class='String'>&quot;⁼&quot;</span></code> are both specific instances of the <code><span class='Modifier'>_ml</span></code> token.</p>
+<pre><span class='Function'>UndoHead</span> <span class='Function'>=</span> <span class='Value'>headW?</span> <span class='Paren'>(</span> <span class='Function'>F</span> <span class='Function'>|</span> <span class='String'>&quot;𝕊&quot;</span> <span class='Paren'>)</span>      <span class='String'>&quot;⁼&quot;</span> <span class='Value'>headX</span>
+         <span class='Function'>|</span> <span class='Value'>headW</span>  <span class='Paren'>(</span> <span class='Function'>F</span> <span class='Function'>|</span> <span class='String'>&quot;𝕊&quot;</span> <span class='Paren'>)</span> <span class='String'>&quot;˜&quot;</span>  <span class='String'>&quot;⁼&quot;</span> <span class='Value'>headX</span>
+         <span class='Function'>|</span>        <span class='Paren'>(</span> <span class='Function'>F</span> <span class='Function'>|</span> <span class='String'>&quot;𝕊&quot;</span> <span class='Paren'>)</span> <span class='String'>&quot;˜&quot;</span><span class='Value'>?</span> <span class='String'>&quot;⁼&quot;</span>
+</pre>
 <p>A braced block contains bodies, which are lists of statements, separated by semicolons and possibly preceded by headers, which are separated from the body with a colon. Multiple bodies allow different handling for various cases, which are pattern-matched by headers. For an immediate block there are no inputs, so there can only be one possible case and one body. Functions and modifiers allow any number of &quot;matched&quot; bodies, with headers that have arguments, followed by at most two &quot;main&quot; bodies with either no headers or headers without arguments. If there is one main body, it is ambivalent, but two main bodies refer to the monadic and dyadic cases.</p>
 <pre><span class='Function'>BODY</span>     <span class='Function'>=</span> <span class='Function'>PROGRAM</span>
 <span class='Function'>FCase</span>    <span class='Function'>=</span> <span class='Separator'>⋄</span><span class='Value'>?</span> <span class='Function'>FuncHead</span> <span class='String'>&quot;:&quot;</span> <span class='Function'>BODY</span>
diff --git a/docs/spec/index.html b/docs/spec/index.html
index 5c2017e1..4f7d4faa 100644
--- a/docs/spec/index.html
+++ b/docs/spec/index.html
@@ -5,7 +5,7 @@
 </head>
 <div class="nav"><a href="https://github.com/mlochbaum/BQN">BQN</a> / <a href="../index.html">main</a></div>
 <h1 id="bqn-specification">BQN specification</h1>
-<p>This document, and the others in this directory (linked in the list below) make up the pre-versioning BQN specification. The specification differs from the <a href="../doc/index.html">documentation</a> in that its purpose is only to describe the exact details of BQN's operation in the most quickly accessible way, rather than to explain the central ideas of BQN functionality and how it might be used. The core of BQN, which excludes system-provided values, is now almost completely specified. Three planned features—syntax for system-provided values, inferred property function headers, and an extension to allow low-rank elements in the argument to Join—have not yet been added, and the spec will continue to be edited further to improve clarity and cover any edge cases that have been missed.</p>
+<p>This document, and the others in this directory (linked in the list below) make up the pre-versioning BQN specification. The specification differs from the <a href="../doc/index.html">documentation</a> in that its purpose is only to describe the exact details of BQN's operation in the most quickly accessible way, rather than to explain the central ideas of BQN functionality and how it might be used. The core of BQN, which excludes system-provided values, is now almost completely specified. Two planned features—syntax for system-provided values and an extension to allow low-rank elements in the argument to Join—have not yet been added, and the spec will continue to be edited further to improve clarity and cover any edge cases that have been missed.</p>
 <p>Under this specification, a language implementation is a <strong>BQN pre-version implementation</strong> if it behaves as specified for all input programs. It is a <strong>BQN pre-version implementation with extensions</strong> if it behaves as specified in all cases where the specification does not require an error, but behaves differently in at least one case where it requires an error. It is a <strong>partial</strong> version of either of these if it doesn't conform to the description but differs from a conforming implementation only by rejecting with an error some programs that the conforming implementation accepts. As the specification is not yet versioned, other instances of the specification define these terms in different ways. An implementation can use one of these term if it conforms to any instance of the pre-versioning BQN specifications that defines them. When versioning is begun, there will be only one specification for each version.</p>
 <p>The following documents are included in the BQN specification. A BQN program is a sequence of <a href="https://en.wikipedia.org/wiki/Unicode">Unicode</a> code points: to evaluate it, it is converted into a sequence of tokens using the token formation rules, then these tokens are arranged in a syntax tree according to the grammar, and then this tree is evaluated according to the evaluation semantics. The program may be evaluated in the presence of additional context such as a filesystem or command-line arguments; this context is presented to the program and manipulated through the system-provided values.</p>
 <ul>
diff --git a/docs/spec/inferred.html b/docs/spec/inferred.html
index 2ff3ce0a..bda3e054 100644
--- a/docs/spec/inferred.html
+++ b/docs/spec/inferred.html
@@ -470,6 +470,8 @@
 </tr>
 </tbody>
 </table>
+<h3 id="undo-headers">Undo headers</h3>
+<p>An <code><span class='Function'>UndoHead</span></code> header specifies how a block function acts when undone. Like ordinary headers, undo headers are searched for a match when a block function <code><span class='Function'>F</span></code> is undone, or when <code><span class='Function'>F</span><span class='Modifier'>˜</span></code> is undone with two arguments (including the two modifier cases <code><span class='Function'>𝔽</span><span class='Modifier2'>⟜</span><span class='Value'>k</span></code> and <code><span class='Function'>𝔽𝔾</span><span class='Value'>k</span></code> from the previous section). An <code><span class='Function'>UndoHead</span></code> without <code><span class='String'>&quot;˜&quot;</span></code> matches the <code><span class='Function'>F</span><span class='Modifier'>⁼</span></code> case while one with <code><span class='String'>&quot;˜&quot;</span></code> matches the <code><span class='Function'>F</span><span class='Modifier'>˜⁼</span></code> case. The left and right arguments are matched to <code><span class='Value'>headW</span></code> and <code><span class='Value'>headX</span></code> as with ordinary headers, and the first matching case is evaluated to give the result of the Undo-derived function.</p>
 <h2 id="under">Under</h2>
 <p>The Under 2-modifier <code><span class='Modifier2'>⌾</span></code> conceptually applies its left operand under the action of its right operand. Setting <code><span class='Value'>z</span><span class='Gets'>←</span><span class='Value'>𝕨</span><span class='Function'>𝔽</span><span class='Modifier2'>⌾</span><span class='Function'>𝔾</span><span class='Value'>𝕩</span></code>, it satisfies <code><span class='Paren'>(</span><span class='Value'>𝕨</span><span class='Function'>𝔽</span><span class='Modifier2'>○</span><span class='Function'>𝔾</span><span class='Value'>𝕩</span><span class='Paren'>)</span> <span class='Function'>≡</span> <span class='Function'>𝔾</span><span class='Value'>z</span></code>. We might say that <code><span class='Function'>𝔾</span></code> transforms values to a new domain, and <code><span class='Modifier2'>⌾</span><span class='Function'>𝔾</span></code> lifts actions <code><span class='Function'>𝔽</span></code> performed in this domain to the original domain of values. For example, addition in the logarithmic domain corresponds to multiplication in the linear domain: <code><span class='Function'>+</span><span class='Modifier2'>⌾</span><span class='Paren'>(</span><span class='Function'>⋆</span><span class='Modifier'>⁼</span><span class='Paren'>)</span></code> is <code><span class='Function'>×</span></code> (but less precise if computed in floating point).</p>
 <p>Let <code><span class='Value'>v</span><span class='Gets'>←</span><span class='Value'>𝕨</span><span class='Function'>𝔽</span><span class='Modifier2'>○</span><span class='Function'>𝔾</span><span class='Value'>𝕩</span></code>, so that <code><span class='Value'>v</span><span class='Function'>≡𝔾</span><span class='Value'>z</span></code>. <code><span class='Value'>v</span></code> is of course well-defined, so the inference step is to find <code><span class='Value'>z</span></code> based on <code><span class='Value'>v</span></code> and possibly the original inputs. We distinguish three cases for Under:</p>