Specify predicates

1 files changed, 5 insertions, 3 deletions

diff --git a/spec/evaluate.md b/spec/evaluate.md
index a508a895..7274722a 100644
--- a/spec/evaluate.md
+++ b/spec/evaluate.md
@@ -14,13 +14,15 @@ As specified, BQN programs can involve an arbitrary amount of information, but w
 
 The result of parsing a valid BQN program is a `PROGRAM`, and the program is run by evaluating this term.
 
-A `PROGRAM` or `BODY` is a list of `STMT`s, which are evaluated in program order. A result is always required for `BODY` nodes, and sometimes for `PROGRAM` nodes (for example, when loaded with `•Import`). If any identifiers in the node's scope are exported, or any of its statements is an `EXPORT`, 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 `STMT` node must be an `EXPR` and its result is used. The statement `EXPR` evaluates some BQN code and possibly assigns the results, while `nothing` evaluates any `subject` or `Derv` terms it contains but discards the results. An `EXPORT` statement performs no action.
+A `PROGRAM` or `BODY` is a list of `STMT`s, which are evaluated in program order. A `BODY` also allows an `EXPR` followed by `"?"` in place of an `STMT`: then the expression is evaluated as usual but its result is checked as discussed below. A result is always required for `BODY` nodes, and sometimes for `PROGRAM` nodes (for example, when loaded with `•Import`). If any identifiers in the node's scope are exported, or any of its statements is an `EXPORT`, 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 `STMT` node must be an `EXPR` and its result is used. The statement `EXPR` evaluates some BQN code and possibly assigns the results, while `nothing` evaluates any `subject` or `Derv` terms it contains but discards the results. An `EXPORT` statement performs no action.
 
-A block consists of several `BODY` terms, some of which may have an accompanying header describing accepted inputs and how they are processed. An immediate block `brImm` can only have one `BODY`, and is evaluated by evaluating the code in it. Other types of blocks do not evaluate any `BODY` immediately, but instead return a function or modifier that obtains its result by evaluating a particular `BODY`. The `BODY` 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. The stored values can be accessed by equality checking, or `•Decompose` if defined. Two calls are required if there is more than one `BODY` term, if the `BODY` contains the special names `𝕨𝕩𝕤𝕎𝕏𝕊`, or if its header specifies arguments (the header-body combination is a `_mCase` or `_cCase_`). Otherwise only one is required.
+A block consists of several `BODY` terms, some of which may have an accompanying header describing accepted inputs and how they are processed. An immediate block `brImm` can only have one `BODY`, and is evaluated by evaluating it. Other types of blocks don't evaluate any `BODY` immediately, but instead return a function or modifier that obtains its result by evaluating a particular `BODY`. The `BODY` 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. The stored values can be accessed by equality checking, or `•Decompose` if defined. Two calls are required if there is more than one `BODY` term, if the `BODY` contains the special names `𝕨𝕩𝕤𝕎𝕏𝕊`, or if its header specifies arguments (the header-body combination is a `_mCase` or `_cCase_`). Otherwise only one is required.
 
 To evaluate a block when enough inputs have been received, first the correct case must be identified. To do this, first each special case (`FCase`, `_mCase`, or `_cCase_`), excluding `FCase` nodes containing `UndoHead`, is checked in order to see if its arguments are strucurally compatible with the given arguments. That is, is `headW` is a `subject`, there must be a left argument matching that structure, and if `headX` is a `subject`, the right argument must match that structure. This means that `𝕨` 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 (`FMain`, `_mMain`, or `_cMain_`) 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.
 
-The only remaining step before evaluating the `BODY` is to bind the inputs and other names. 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.
+When a predicate `"?"` is evaluated, it may change the choice of case. The associated `EXPR` is evaluated and its result is checked. If it's not one of the numbers `0` or `1`, an error results. If it's `1`, evaluation of the `BODY` continues as usual. If it's `0`, evaluation is stopped and the next compatible `BODY` term is evaluated using the block's original inputs.
+
+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.
 
 If there is no left argument, but the `BODY` contains `𝕨` or `𝕎` at the top level, then it is conceptually re-parsed with `𝕨` replaced by `·` to give a monadic version before application; this modifies the syntax tree by replacing some instances of `subject`, `arg`, or `Operand` with `nothing`. The token `𝕎` is not allowed in this case and causes an error. Re-parsing `𝕨` can also cause an error if it's used as an operand or list element, where `nothing` is not allowed by the grammar. Note that these errors must not appear if the block is always called with two arguments. True re-parsing 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; and if it's used in another context then it causes an error.