You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<p>A <code><spanclass='Function'>PROGRAM</span></code> or <code><spanclass='Function'>BODY</span></code> is a list of <code><spanclass='Function'>STMT</span></code>s, which are evaluated in program order. A <code><spanclass='Function'>BODY</span></code> also allows an <code><spanclass='Function'>EXPR</span></code> followed by <code><spanclass='String'>"?"</span></code> in place of an <code><spanclass='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><spanclass='Function'>BODY</span></code> nodes, and sometimes for <code><spanclass='Function'>PROGRAM</span></code> nodes (for example, when loaded with <code><spanclass='Function'>•Import</span></code>). If any identifiers in the node's scope are exported, or any of its statements is an <code><spanclass='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><spanclass='Function'>STMT</span></code> node must be an <code><spanclass='Function'>EXPR</span></code> and its result is used. The statement <code><spanclass='Function'>EXPR</span></code> evaluates some BQN code and possibly assigns the results, while <code><spanclass='Value'>nothing</span></code> evaluates any <code><spanclass='Value'>subject</span></code> or <code><spanclass='Function'>Derv</span></code> terms it contains but discards the results. An <code><spanclass='Function'>EXPORT</span></code> statement performs no action.</p>
16
16
<p>A block consists of several <code><spanclass='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><spanclass='Value'>blSub</span></code> is evaluated when reached. Other types of blocks don't evaluate any <code><spanclass='Function'>BODY</span></code> immediately, but instead return a function or modifier that obtains its result by evaluating a particular <code><spanclass='Function'>BODY</span></code>. The <code><spanclass='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><spanclass='Function'>IMM_BLK</span></code> and two for an <code><spanclass='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><spanclass='Function'>•Decompose</span></code> if defined.</p>
17
17
<p>To evaluate a block when enough inputs have been received, each case (<code><spanclass='Function'>I_CASE</span></code>, <code><spanclass='Function'>A_CASE</span></code>, or <code><spanclass='Function'>S_CASE</span></code>), excluding <code><spanclass='Function'>A_CASE</span></code> nodes whose <code><spanclass='Function'>ARG_HEAD</span></code> contains <code><spanclass='String'>"⁼"</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><spanclass='Function'>ARG_BLK</span></code> block and a left argument is given—this will be handled by the second case.</p>
18
+
<p>A <code><spanclass='Function'>BODY</span></code> taking arguments is ambivalent if it has no header and every other <code><spanclass='Function'>BODY</span></code> in its block has one, or if its header contains <code><spanclass='Value'>𝕨</span></code>. If such a <code><spanclass='Function'>BODY</span></code> contains <code><spanclass='Value'>𝕨</span></code> or <code><spanclass='Function'>𝕎</span></code> at the top level, and is called with no left argument, then it is conceptually re-parsed with <code><spanclass='Value'>𝕨</span></code> replaced by <code><spanclass='Nothing'>·</span></code> to give a monadic version before application. The token <code><spanclass='Function'>𝕎</span></code> is not allowed in this case and causes an error. There can also be an error if <code><spanclass='Value'>𝕨</span></code> appears where <code><spanclass='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><spanclass='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><spanclass='Value'>subject</span></code>, <code><spanclass='Value'>arg</span></code>, or <code><spanclass='Function'>Operand</span></code> with <code><spanclass='Value'>nothing</span></code>. Explicitly constructing this tree is not required, as the same effect can also be achieved dynamically by treating <code><spanclass='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><spanclass='Nothing'>·</span></code> is "returned" immediately.</p>
18
19
<p>If a case has a header, then it must structurally match the inputs to begin evaluation. That is, if <code><spanclass='Value'>headX</span></code> is an <code><spanclass='Value'>lhs</span></code>, the right argument must match that structure, and similarly for <code><spanclass='Function'>HeadF</span></code> with a left operand and <code><spanclass='Function'>HeadG</span></code> with a right operand. If <code><spanclass='Value'>headW</span></code> is an <code><spanclass='Value'>lhs</span></code>, there must be a left argument matching that structure. This means that <code><spanclass='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><spanclass='Function'>BODY</span></code> is begun. Special names are always bound when applicable: <code><spanclass='Value'>𝕨𝕩𝕤</span></code> if arguments are used, <code><spanclass='Value'>𝕨</span></code> if there is a left argument, <code><spanclass='Value'>𝕗𝕘</span></code> if operands are used, and <code><spanclass='Modifier'>_𝕣</span></code> and <code><spanclass='Modifier2'>_𝕣_</span></code> for modifiers and combinators, respectively. Any names in the header are also bound, allowing multiple assignment for arguments.</p>
19
20
<p>When a predicate <code><spanclass='String'>"?"</span></code> is evaluated, the associated <code><spanclass='Function'>EXPR</span></code> is evaluated and its result is checked. If it's not one of the numbers <code><spanclass='Number'>0</span></code> or <code><spanclass='Number'>1</span></code>, an error results. If it's <code><spanclass='Number'>1</span></code>, evaluation of the <code><spanclass='Function'>BODY</span></code> continues as usual. If it's <code><spanclass='Number'>0</span></code>, evaluation is stopped and the next compatible <code><spanclass='Function'>BODY</span></code> term is evaluated using the block's original inputs.</p>
20
-
<p>If there is no left argument, but the <code><spanclass='Function'>BODY</span></code> contains <code><spanclass='Value'>𝕨</span></code> or <code><spanclass='Function'>𝕎</span></code> at the top level, then it is conceptually re-parsed with <code><spanclass='Value'>𝕨</span></code> replaced by <code><spanclass='Nothing'>·</span></code> to give a monadic version before application; this modifies the syntax tree by replacing some instances of <code><spanclass='Value'>subject</span></code>, <code><spanclass='Value'>arg</span></code>, or <code><spanclass='Function'>Operand</span></code> with <code><spanclass='Value'>nothing</span></code>. The token <code><spanclass='Function'>𝕎</span></code> is not allowed in this case and causes an error. Re-parsing <code><spanclass='Value'>𝕨</span></code> can also cause an error if it's used as an operand or list element, where <code><spanclass='Value'>nothing</span></code> 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 <code><spanclass='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><spanclass='Nothing'>·</span></code> is "returned" immediately; and if it's used in another context then it causes an error.</p>
<p>An <em>assignment</em> is one of the four rules containing <code><spanclass='Function'>ASGN</span></code>. It is evaluated by first evaluating the right-hand-side <code><spanclass='Value'>subExpr</span></code>, <code><spanclass='Function'>FuncExpr</span></code>, <code><spanclass='Modifier'>_m1Expr</span></code>, or <code><spanclass='Modifier2'>_m2Exp_</span></code> expression, and then storing the result in the left-hand-side identifier or identifiers. The result of the assignment expression is the result of its right-hand side. Except for subjects, only a lone identifier is allowed on the left-hand side and storage sets it equal to the result. For subjects, <em>destructuring assignment</em> is performed when an <code><spanclass='Value'>lhs</span></code> is <code><spanclass='Value'>lhsList</span></code>, <code><spanclass='Value'>lhsStr</span></code>, or <code><spanclass='Value'>lhsArray</span></code>. Destructuring assignment is performed recursively by assigning right-hand-side values to the left-hand-side targets, with single-identifier assignment as the base case. The target <code><spanclass='String'>"·"</span></code> is also possible in place of a <code><spanclass='Function'>NAME</span></code>, and performs no assignment.</p>
23
23
<p>In assignment to <code><spanclass='Value'>lhsList</span></code> or <code><spanclass='Value'>lhsStr</span></code>, the right-hand-side value, here called <code><spanclass='Value'>v</span></code>, must be a list (rank 1 array) or namespace. If it's a list, then each <code><spanclass='Function'>LHS_ENTRY</span></code> node must be an <code><spanclass='Function'>LHS_ELT</span></code>. The left-hand side is treated as a list of <code><spanclass='Value'>lhs</span></code> targets, and matched to <code><spanclass='Value'>v</span></code> element-wise, with an error if the two lists differ in length. If <code><spanclass='Value'>v</span></code> is a namespace, then the left-hand side must be an <code><spanclass='Value'>lhsStr</span></code> where every <code><spanclass='Function'>LHS_ATOM</span></code> is an <code><spanclass='Function'>NAME</span></code>, or an <code><spanclass='Value'>lhsList</span></code> where every <code><spanclass='Function'>LHS_ENTRY</span></code> is an <code><spanclass='Function'>NAME</span></code> or <code><spanclass='Value'>lhs</span><spanclass='String'>"⇐"</span><spanclass='Function'>NAME</span></code>, so that it can be considered a list of <code><spanclass='Function'>NAME</span></code> nodes some of which are also associated with <code><spanclass='Value'>lhs</span></code> nodes. To perform the assignment, the value of each name is obtained from the namespace <code><spanclass='Value'>v</span></code>, giving an error if <code><spanclass='Value'>v</span></code> does not define that name. The value is assigned to the <code><spanclass='Value'>lhs</span></code> node if present (which may be a destructuring assignment or simple subject assignment), and otherwise assigned to the same <code><spanclass='Function'>NAME</span></code> node used to get it from <code><spanclass='Value'>v</span></code>.</p>
Copy file name to clipboardexpand all lines: spec/evaluate.md
+2-2
Original file line number
Diff line number
Diff line change
@@ -20,12 +20,12 @@ A block consists of several `BODY` terms, some of which may have an accompanying
20
20
21
21
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.
22
22
23
+
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.
24
+
23
25
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.
24
26
25
27
When a predicate `"?"` is evaluated, 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.
26
28
27
-
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.
28
-
29
29
### Assignment
30
30
31
31
An *assignment* is one of the four rules containing `ASGN`. It is evaluated by first evaluating the right-hand-side `subExpr`, `FuncExpr`, `_m1Expr`, or `_m2Exp_` expression, and then storing the result in the left-hand-side identifier or identifiers. The result of the assignment expression is the result of its right-hand side. Except for subjects, only a lone identifier is allowed on the left-hand side and storage sets it equal to the result. For subjects, *destructuring assignment* is performed when an `lhs` is `lhsList`, `lhsStr`, or `lhsArray`. Destructuring assignment is performed recursively by assigning right-hand-side values to the left-hand-side targets, with single-identifier assignment as the base case. The target `"·"` is also possible in place of a `NAME`, and performs no assignment.
0 commit comments