From 229e2cd2f5c78b13c483a8559dead2c8f31d8e42 Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Sat, 18 Jul 2020 18:26:52 -0400 Subject: Terminology changes: subject, 1/2-modifier, Box/Unbox to Enclose/Merge, blocks --- docs/spec/evaluate.html | 44 ++++++++++++++++++++++---------------------- 1 file changed, 22 insertions(+), 22 deletions(-) (limited to 'docs/spec/evaluate.html') diff --git a/docs/spec/evaluate.html b/docs/spec/evaluate.html index 6552f80e..7ebbe147 100644 --- a/docs/spec/evaluate.html +++ b/docs/spec/evaluate.html @@ -4,16 +4,16 @@

Programs and blocks

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 STMTs (for BODY, the last must be an EXPR, a particular kind of STMT), which are evaluated in program order. The statement nothing does nothing when evaluated, while EXPR evaluates some APL code and possibly assigns the results, as described below.

-

A block consists of several BODY terms, some of which may have an accompanying header describing accepted inputs and how they are processed. A value block brVal 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, modifier, or operator 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 and compositions 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 BODY term, if the BODY contains the special names ๐•จ๐•ฉ๐•ค๐•Ž๐•๐•Š, or if its header specifies arguments (the header-body 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_) is checked in order to see if its arguments are strucurally compatible with the given arguments. That is, is headW is a value, there must be a left argument matching that structure, and if headX is a value, 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.

+

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. 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_) 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.

If there is no left argument, but the BODY contains ๐•จ at the top level, then it is conceptually re-parsed with ๐•จ replaced by ยท to give a monadic version before application. As the only effect when this re-parsed form is valid is to change some instances of arg to nothing, this can be achieved efficiently by annotating parts of the AST that depend on ๐•จ as conditionally-nothing. However, it also causes an error if ๐•จ is used as an operand or list element, where nothing is not allowed by the grammar.

Assignment

-

An assignment is one of the four rules containing ASGN. It is evaluated by first evaluating the right-hand-side valExpr, FuncExpr, _modExpr, or _cmpExp_ 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 values, only a lone identifier is allowed on the left-hand side and storage is obvious. For values, multiple assignment with a list left-hand side is also allowed. Multiple assignment is performed recursively by assigning right-hand-side values to the left-hand-side targets, with single-identifier (v) assignment as the base case. When matching the right-hand side to a list left-hand side, the left hand side is treated as a list of lhs targets. The evaluated right-hand side must be a list (rank-1 array) of the same length, and is matched to these targets element-wise.

-

Modified assignment is the value assignment rule lhs Derv "โ†ฉ" valExpr. In this case, lhs should be evaluated as if it were a valExpr (the syntax is a subset of valExpr), and the result of the function application lhs Derv valExpr should be assigned to lhs, and is also the result of the modified assignment expression.

+

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 is obvious. For subjects, multiple assignment with a list left-hand side is also allowed. Multiple assignment is performed recursively by assigning right-hand-side values to the left-hand-side targets, with single-identifier (s) assignment as the base case. When matching the right-hand side to a list left-hand side, the left hand side is treated as a list of lhs targets. The evaluated right-hand side must be a list (rank-1 array) of the same length, and is matched to these targets element-wise.

+

Modified assignment is the subject assignment rule lhs Derv "โ†ฉ" subExpr. In this case, lhs should be evaluated as if it were a subExpr (the syntax is a subset of subExpr), and the result of the function application lhs Derv subExpr should be assigned to lhs, and is also the result of the modified assignment expression.

Expressions

-

We now give rules for evaluating an atom, Func, _mod or _comp_ expression (the possible options for ANY). A literal vl, Fl, _ml, or _cl_ has a fixed value defined by the specification (value literals and built-ins). An identifier v, F, _m, or _c_ is evaluated by returning its value; because of the scoping rules it must have one when evaluated. A parenthesized expression such as "(" _modExpr ")" simply returns the result of the interior expression. A braced construct such as BraceFunc is defined by the evaluation of the statements it contains after all parameters are accepted. Finally, a list "โŸจ" โ‹„? ( ( EXPR โ‹„ )* EXPR โ‹„? )? "โŸฉ" or ANY ( "โ€ฟ" ANY )+ consists grammatically of a list of expressions. To evaluate it, each expression is evaluated in source order and their results are placed as elements of a rank-1 array. The two forms have identical semantics but different punctuation.

-

Rules in the table below are function and operator evaluation.

+

We now give rules for evaluating an atom, Func, _mod1 or _mod2_ expression (the possible options for ANY). A literal or primitive sl, Fl, _ml, or _cl_ has a fixed value defined by the specification (literals and built-ins). An identifier s, F, _m, or _c_ is evaluated by returning its value; because of the scoping rules it must have one when evaluated. A parenthesized expression such as "(" _modExpr ")" simply returns the result of the interior expression. A braced construct such as BraceFunc is defined by the evaluation of the statements it contains after all parameters are accepted. Finally, a list "โŸจ" โ‹„? ( ( EXPR โ‹„ )* EXPR โ‹„? )? "โŸฉ" or ANY ( "โ€ฟ" ANY )+ consists grammatically of a list of expressions. To evaluate it, each expression is evaluated in source order and their results are placed as elements of a rank-1 array. The two forms have identical semantics but different punctuation.

+

Rules in the table below are function and modifier evaluation.

@@ -28,32 +28,32 @@ - + - + - + - + - - + + - +
๐•จ( value | nothing )?( subject | nothing )? Derv arg ๐•ฉFunction, valueFunction, subject
๐•— Operand_mod_mod1 Modifier1-Modifier
๐•— Operand_comp_( value | Func )_mod2_( subject | Func ) ๐•˜Composition2-Modifier
-

In each case the constituent expressions are evaluated in reverse source order: Right, then Called, then Left. Then the expression's result is obtained by calling the Called value on its parameters. A left argument of nothing is not used as a parameter, leaving only a right argument in that case. The data type of the Called value must be appropriate to the expression type, as indicated in the "Types" column. For function application, a value type (number, character, or array) is allowed. It is called simply by returning itself. Although the arguments are ignored in this case, they are still evaluated. A braced construct is evaluated by binding the parameter names given in columns L and R to the corresponding values. Then if all parameter levels present have been bound, its body is evaluated to give the result of application.

-

The following rules derive new functions or operators from existing ones.

+

In each case the constituent expressions are evaluated in reverse source order: Right, then Called, then Left. Then the expression's result is obtained by calling the Called value on its parameters. A left argument of nothing is not used as a parameter, leaving only a right argument in that case. The type of the Called value must be appropriate to the expression type, as indicated in the "Types" column. For function application, a data type (number, character, or array) is allowed. It is called simply by returning itself. Although the arguments are ignored in this case, they are still evaluated. A braced construct is evaluated by binding the parameter names given in columns L and R to the corresponding values. Then if all parameter levels present have been bound, its body is evaluated to give the result of application.

+

The following rules derive new functions or modifiers from existing ones.

@@ -66,15 +66,15 @@ - - - + + + - + - + @@ -90,5 +90,5 @@
_comp_( value | Func ){๐”ฝ _C_ R}_mod2_( subject | Func ){๐”ฝ _C_ R}
Operand_comp__mod2_ {L _C_ ๐”ฝ}{L _C_ ๐”ฝ}
Operand
-

As with applications, all expressions are evaluated in reverse source order before doing anything else. Then a result is formed without calling the center value. Its value in BQN is given in the rightmost column, using L, C, and R for the results of the expressions in the left, center, and right columns, respectively. For the first two rules (partial application), the given operand is bound to the composition: the result is a modifier that, when called, calls the center composition with the bound operand on the same side it appeared on and the new operand on the remaining side. A train is a function that, when called, calls the right-hand function on all arguments, then the left-hand function, and calls the center function with these results as arguments. In a composition partial application, the result will fail when applied if the center value does not have the composition type, and in a fork, it will fail if any component has a modifier or composition type (that is, cannot be applied as a function). BQN implementations are not required to check for these types when forming the result of these expressions, but may give an error on formation even if the result will never be applied.

+

As with applications, all expressions are evaluated in reverse source order before doing anything else. Then a result is formed without calling the center value. Its value in BQN is given in the rightmost column, using L, C, and R for the results of the expressions in the left, center, and right columns, respectively. For the first two rules (partial application), the given operand is bound to the 2-modifier: the result is a 1-modifier that, when called, calls the center 2-modifier with the bound operand on the same side it appeared on and the new operand on the remaining side. A train is a function that, when called, calls the right-hand function on all arguments, then the left-hand function, and calls the center function with these results as arguments. In a modifier partial application, the result will fail when applied if the center value does not have the 2-modifier type, and in a fork, it will fail if any component has a modifier type (that is, cannot be applied as a function). BQN implementations are not required to check for these types when forming the result of these expressions, but may give an error on formation even if the result will never be applied.

-- cgit v1.2.3