aboutsummaryrefslogtreecommitdiff
path: root/spec/evaluate.md
diff options
context:
space:
mode:
authorMarshall Lochbaum <mwlochbaum@gmail.com>2021-04-16 20:39:10 -0400
committerMarshall Lochbaum <mwlochbaum@gmail.com>2021-04-16 20:39:10 -0400
commit225a30537acfeb3efe2a7730e5d1a063cc537047 (patch)
tree5156e88b11ab1a3baccded91c77acbe8670f02ce /spec/evaluate.md
parent2a06176dd6920c26f02e63f8a3f266b59d10a7ed (diff)
Add return functions to the spec
Diffstat (limited to 'spec/evaluate.md')
-rw-r--r--spec/evaluate.md6
1 files changed, 4 insertions, 2 deletions
diff --git a/spec/evaluate.md b/spec/evaluate.md
index e3cd2666..0ad6bf10 100644
--- a/spec/evaluate.md
+++ b/spec/evaluate.md
@@ -6,7 +6,7 @@ This page describes the semantics of the code constructs whose grammar is given
Here we assume that the referent of each identifier, or equivalently the connections between identifiers, have been identified according to the [scoping rules](scope.md).
-Errors described in this page are "evaluation errors" and can be caught by the Catch (`⎊`) modifier. If an error is caught, evaluation halts without attempting to complete any in-progress node, and is restarted as part of the execution of Catch.
+Evaluation is an ordered process, and any actions required to evaluate a node always have a specified order unless performing them in any order would have the same effect. Side effects that are relevant to ordering are setting and getting the value of a variable, causing an error, and returning (with `→`) from a block. Errors described in this page are "evaluation errors" and can be caught by the Catch (`⎊`) modifier. For caught errors and returns, evaluation halts without attempting to complete any in-progress node, and is restarted by Catch (for errors) or at the end of the appropriate block evaluation (for returns).
### Programs and blocks
@@ -16,7 +16,7 @@ A `PROGRAM` or `BODY` is a list of `STMT`s, which are evaluated in program order
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_`), 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.
+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.
@@ -34,6 +34,8 @@ The right-hand-side value, here called `v`, in destructuring assignment must be
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](literal.md) and [built-ins](primitive.md)). An identifier `s`, `F`, `_m`, or `_c_`, if not preceded by `atom "."`, must have an associated variable due to the scoping rules, and returns this variable's value, or causes an error if it has not yet been set. If it is preceded by `atom "."`, then the `atom` node is evaluated first; its value must be a namespace, and the result is the value of the identifier's name in the namespace, or an error if the name is undefined. 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.
+A `Return` node creates a return function. As [discussed](scope.md#returns) in the scoping rules, its identifier indicates a namespace from a particular block evaluation. When called, the function causes an error if that block has finished execution, or if the call includes a left argument `𝕨`. Otherwise, evaluation stops immediately, and resumes at the end of the block where it returns the right argument `𝕩` from that block.
+
Rules in the table below are function and modifier evaluation.
| L | Left | Called | Right | R | Types
|-----|---------------------------|----------|-----------------------|-----|-----------