Not all header-less bodies are general cases because predicates

Author: mlochbaum

docs/spec/evaluate.html

@@ -15,7 +15,7 @@ <h3 id="programs-and-blocks"><a class="header" href="#programs-and-blocks">Progr
 <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 <code><span class='Function'>BODY</span></code> also allows an <code><span class='Function'>EXPR</span></code> followed by <code><span class='String'>&quot;?&quot;</span></code> in place of an <code><span class='Function'>STMT</span></code>: then the expression is evaluated as usual but its result is checked as discussed below. 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 BQN 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'>blSub</span></code> is evaluated when reached. Other types of blocks don't 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 takes one call for an <code><span class='Function'>IMM_BLK</span></code> and two for an <code><span class='Function'>ARG_BLK</span></code>. If two calls are required, then on the first call the operands are simply stored and no code is evaluated yet. The stored values can be accessed by equality checking, or <code><span class='Function'>•Decompose</span></code> if defined.</p>
 <p>To evaluate a block when enough inputs have been received, each case (<code><span class='Function'>I_CASE</span></code>, <code><span class='Function'>A_CASE</span></code>, or <code><span class='Function'>S_CASE</span></code>), excluding <code><span class='Function'>A_CASE</span></code> nodes whose <code><span class='Function'>ARG_HEAD</span></code> contains <code><span class='String'>&quot;⁼&quot;</span></code>, is tried in order. If any case completes, the block returns the result of that evaluation, and if all cases are tried but none finishes, an error results. A case might not complete because of an incompatible header or failed predicate, as described below. A general case (one with no header or predicates, as defined in the grammar) is always compatible, unless it is the first of two general cases in an <code><span class='Function'>ARG_BLK</span></code> block and a left argument is given—this will be handled by the second case.</p>
-<p>A <code><span class='Function'>BODY</span></code> taking arguments is ambivalent if it has no header and every other <code><span class='Function'>BODY</span></code> in its block has one, or if its header contains <code><span class='Value'>𝕨</span></code>. If such a <code><span class='Function'>BODY</span></code> contains <code><span class='Value'>𝕨</span></code> or <code><span class='Function'>𝕎</span></code> at the top level, and is called with no left argument, 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. The token <code><span class='Function'>𝕎</span></code> is not allowed in this case and causes an error. There can also be an error if <code><span class='Value'>𝕨</span></code> appears where <code><span class='Value'>nothing</span></code> is not allowed by the grammar, such as in a block result, predicate, or operand. Any error occurs when the <code><span class='Function'>BODY</span></code> is actually evaluated with one argument, and before header structure checking. Otherwise, the syntax tree is effectively modified by replacing some instances of <code><span class='Value'>subject</span></code>, <code><span class='Value'>arg</span></code>, or <code><span class='Function'>Operand</span></code> with <code><span class='Value'>nothing</span></code>. Explicitly constructing this tree is not required, as 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's used as a left argument, then the function should instead be called with no left argument (and similarly in trains). If it's 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.</p>
+<p>A <code><span class='Function'>BODY</span></code> taking arguments is ambivalent if it is the only general case in a block, or if its header contains <code><span class='Value'>𝕨</span></code>. If such a <code><span class='Function'>BODY</span></code> contains <code><span class='Value'>𝕨</span></code> or <code><span class='Function'>𝕎</span></code> at the top level, and is called with no left argument, 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. The token <code><span class='Function'>𝕎</span></code> is not allowed in this case and causes an error. There can also be an error if <code><span class='Value'>𝕨</span></code> appears where <code><span class='Value'>nothing</span></code> is not allowed by the grammar, such as in a block result, predicate, or operand. Any error occurs when the <code><span class='Function'>BODY</span></code> is actually evaluated with one argument, and before header structure checking. Otherwise, the syntax tree is effectively modified by replacing some instances of <code><span class='Value'>subject</span></code>, <code><span class='Value'>arg</span></code>, or <code><span class='Function'>Operand</span></code> with <code><span class='Value'>nothing</span></code>. Explicitly constructing this tree is not required, as 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's used as a left argument, then the function should instead be called with no left argument (and similarly in trains). If it's 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.</p>
 <p>If a case has a header, then it must structurally match the inputs to begin evaluation. That is, if <code><span class='Value'>headX</span></code> is an <code><span class='Value'>lhs</span></code>, the right argument must match that structure, and similarly for <code><span class='Function'>HeadF</span></code> with a left operand and <code><span class='Function'>HeadG</span></code> with a right operand. If <code><span class='Value'>headW</span></code> is an <code><span class='Value'>lhs</span></code>, there must be a left argument matching 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 destructuring assignment described below, except that the header may contain constants, which must match the corresponding part of the given argument. For a compatible header, inputs and other names are bound when evaluation of a <code><span class='Function'>BODY</span></code> is begun. 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>When a predicate <code><span class='String'>&quot;?&quot;</span></code> is evaluated, the associated <code><span class='Function'>EXPR</span></code> is evaluated and its result is checked. If it's not one of the numbers <code><span class='Number'>0</span></code> or <code><span class='Number'>1</span></code>, an error results. If it's <code><span class='Number'>1</span></code>, evaluation of the <code><span class='Function'>BODY</span></code> continues as usual. If it's <code><span class='Number'>0</span></code>, evaluation is stopped and the next compatible <code><span class='Function'>BODY</span></code> term is evaluated using the block's original inputs.</p>
 <h3 id="assignment"><a class="header" href="#assignment">Assignment</a></h3>

spec/evaluate.md

@@ -20,7 +20,7 @@ A block consists of several `BODY` terms, some of which may have an accompanying
 
 To evaluate a block when enough inputs have been received, each case (`I_CASE`, `A_CASE`, or `S_CASE`), excluding `A_CASE` nodes whose `ARG_HEAD` contains `"⁼"`, is tried in order. If any case completes, the block returns the result of that evaluation, and if all cases are tried but none finishes, an error results. A case might not complete because of an incompatible header or failed predicate, as described below. A general case (one with no header or predicates, as defined in the grammar) is always compatible, unless it is the first of two general cases in an `ARG_BLK` block and a left argument is given—this will be handled by the second case.
 
-A `BODY` taking arguments is ambivalent if it has no header and every other `BODY` in its block has one, or if its header contains `𝕨`. If such a `BODY` contains `𝕨` or `𝕎` at the top level, and is called with no left argument, then it is conceptually re-parsed with `𝕨` replaced by `·` to give a monadic version before application. The token `𝕎` is not allowed in this case and causes an error. There can also be an error if `𝕨` appears where `nothing` is not allowed by the grammar, such as in a block result, predicate, or operand. Any error occurs when the `BODY` is actually evaluated with one argument, and before header structure checking. Otherwise, the syntax tree is effectively modified by replacing some instances of `subject`, `arg`, or `Operand` with `nothing`. Explicitly constructing this tree is not required, as the same effect can also be achieved dynamically by treating `·` as a value and checking for it during execution. If it's used as a left argument, then the function should instead be called with no left argument (and similarly in trains). If it's used as a right argument, then the function and its left argument are evaluated but, rather than calling the function, `·` is "returned" immediately.
+A `BODY` taking arguments is ambivalent if it is the only general case in a block, or if its header contains `𝕨`. If such a `BODY` contains `𝕨` or `𝕎` at the top level, and is called with no left argument, then it is conceptually re-parsed with `𝕨` replaced by `·` to give a monadic version before application. The token `𝕎` is not allowed in this case and causes an error. There can also be an error if `𝕨` appears where `nothing` is not allowed by the grammar, such as in a block result, predicate, or operand. Any error occurs when the `BODY` is actually evaluated with one argument, and before header structure checking. Otherwise, the syntax tree is effectively modified by replacing some instances of `subject`, `arg`, or `Operand` with `nothing`. Explicitly constructing this tree is not required, as the same effect can also be achieved dynamically by treating `·` as a value and checking for it during execution. If it's used as a left argument, then the function should instead be called with no left argument (and similarly in trains). If it's used as a right argument, then the function and its left argument are evaluated but, rather than calling the function, `·` is "returned" immediately.
 
 If a case has a header, then it must structurally match the inputs to begin evaluation. That is, if `headX` is an `lhs`, the right argument must match that structure, and similarly for `HeadF` with a left operand and `HeadG` with a right operand. If `headW` is an `lhs`, there must be a left argument matching that structure. This means that `𝕨` not only matches any left argument but also no argument. The test for compatibility is the same as for destructuring assignment described below, except that the header may contain constants, which must match the corresponding part of the given argument. For a compatible header, inputs and other names are bound when evaluation of a `BODY` is begun. Special names are always bound when applicable: `𝕨𝕩𝕤` if arguments are used, `𝕨` if there is a left argument, `𝕗𝕘` if operands are used, and `_𝕣` and `_𝕣_` for modifiers and combinators, respectively. Any names in the header are also bound, allowing multiple assignment for arguments.