Add return functions to the spec

4 files changed, 17 insertions, 7 deletions

diff --git a/spec/README.md b/spec/README.md
index 0f22e3ec..ee5c1846 100644
--- a/spec/README.md
+++ b/spec/README.md
@@ -2,7 +2,7 @@
 
 # BQN specification
 
-This document, and the others in this directory (linked in the list below) make up the pre-versioning BQN specification. The specification differs from the [documentation](../doc/README.md) in that its purpose is only to describe the exact details of BQN's operation in the most quickly accessible way, rather than to explain the central ideas of BQN functionality and how it might be used. The core of BQN, which excludes system-provided values, is now almost completely specified. One planned features—an extension to allow low-rank elements in the argument to Join—has not yet been added, and the spec will continue to be edited further to improve clarity and cover any edge cases that have been missed.
+This document, and the others in this directory (linked in the list below) make up the pre-versioning BQN specification. The specification differs from the [documentation](../doc/README.md) in that its purpose is only to describe the exact details of BQN's operation in the most quickly accessible way, rather than to explain the central ideas of BQN functionality and how it might be used. The core of BQN, which excludes system-provided values, is now almost completely specified. One planned feature—an extension to allow low-rank elements in the argument to Join—has not yet been added, and the spec will continue to be edited further to improve clarity and cover any edge cases that have been missed.
 
 Under this specification, a language implementation is a **BQN pre-version implementation** if it behaves as specified for all input programs. It is a **BQN pre-version implementation with extensions** if it behaves as specified in all cases where the specification does not require an error, but behaves differently in at least one case where it requires an error. It is a **partial** version of either of these if it doesn't conform to the description but differs from a conforming implementation only by rejecting with an error some programs that the conforming implementation accepts. As the specification is not yet versioned, other instances of the specification define these terms in different ways. An implementation can use one of these term if it conforms to any instance of the pre-versioning BQN specifications that defines them. When versioning is begun, there will be only one specification for each version.
 
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
 |-----|---------------------------|----------|-----------------------|-----|-----------
diff --git a/spec/grammar.md b/spec/grammar.md
index c79cbc71..1cc31126 100644
--- a/spec/grammar.md
+++ b/spec/grammar.md
@@ -34,11 +34,13 @@ Starting at the highest-order objects, modifiers have fairly simple syntax. In m
              | Operand _mod2_             # Left partial application
              | _m  ASGN _m1Expr
 
-Functions can be formed by fully applying modifiers or as trains. modifiers are left-associative, so that the left operand (`Operand`) can include modifier applications but the right operand (`subject | Func`) cannot. Trains are right-associative, but bind less tightly than modifiers. Assignment is not allowed in the top level of a train: it must be parenthesized.
+Functions can be formed by fully applying modifiers, as trains, or with the return token `→`, which behaves syntactically like a 1-modifier whose operand must be an identifier. Modifiers are left-associative, so that the left operand (`Operand`) can include modifier applications but the right operand (`subject | Func`) cannot. Trains are right-associative, but bind less tightly than modifiers. Assignment is not allowed in the top level of a train: it must be parenthesized.
 
     Derv     = Func
              | Operand _mod1
              | Operand _mod2_ ( subject | Func )
+             | Return
+    Return   = ( NAME | "𝕊" | "𝕣" ) "→"
     Operand  = subject
              | Derv
     Fork     = Derv
@@ -55,11 +57,11 @@ Subject expressions are complicated by the possibility of list and namespace ass
              | ( subject | nothing )? Derv arg
     nothing  = "·"
              | ( subject | nothing )? Derv nothing
-    LHS_NAME = s | F | _m | _c_
-    LHS_ANY  = LHS_NAME | lhsList
+    NAME     = s | F | _m | _c_
+    LHS_ANY  = NAME | lhsList
     LHS_ATOM = LHS_ANY | "(" lhsStr ")"
     LHS_ELT  = LHS_ANY | lhsStr
-    LHS_ENTRY= LHS_ELT | lhs "⇐" LHS_NAME
+    LHS_ENTRY= LHS_ELT | lhs "⇐" NAME
     lhsStr   = LHS_ATOM ( "‿" LHS_ATOM )+
     lhsList  = "⟨" ⋄? ( ( LHS_ENTRY ⋄ )* LHS_ENTRY ⋄? )? "⟩"
     lhs      = s | lhsList | lhsStr
diff --git a/spec/scope.md b/spec/scope.md
index b25c0ce0..26b924c8 100644
--- a/spec/scope.md
+++ b/spec/scope.md
@@ -20,6 +20,8 @@ The definition for an identifier is chosen from the potential definitions based
 
 The definition of *program order* for identifier tokens follows the order of BQN [execution](evaluate.md). It corresponds to the order of a particular traversal of the abstract syntax tree for a program. To find the relative ordering of two identifiers in a program, we consider the highest-depth node that they both belong to; in this node they must occur in different components, or that component would be a higher-depth node containing both of them. In most nodes, the program order goes from right to left: components further to the right come earlier in program order. The exceptions are `PROGRAM`, `BODY`, `NS_BODY`, `list`, `subject` (for stranding), and body case (`FCase`, `_mCase`, `_cCase_`, `FMain`, `_mMain`, `_cMain_`, `brSub`, `BrFunc`, `_brMod1`, and `_brMod2_`) nodes, in which program order goes in the opposite order, from left to right (some assignment target nodes also contain lists or strands, but their ordering is irrelevant because if two identifiers with the same name appear in such a list, then it can't be a definition).
 
+A subject label is the `s` term in a `brSub` node. As part of a header, it can serve as the definition for an identifier. However, it's defined to be a syntax error if another instance of this identifier appears, except in a `Return` node (which cannot access its value).
+
 ### Special names
 
 Special names such as `𝕩` or `𝕣` refer to variables, but have no definition and do not use scoping. Instead, they always refer to the immediately enclosing scope, and are defined automatically when the block is evaluated.
@@ -41,3 +43,7 @@ When a body in a block is evaluated, it creates a *namespace*, which contains a
 The first access to a variable must be made by its definition (this also means it sets the variable). If a different instance of its identifier accesses it first, then an error results. This can happen because every scope contained in a particular scope sees all the definitions it uses, and such a scope could be called before the definition is run. Because of conditional execution, this property must be checked at run time in general; however, in cases where it is possible to statically determine that a program will always violate it, a BQN instance can give an error at compile time rather than run time.
 
 A namespace defines a mapping from names to variables: if the given name is shared by an exported identifier in the body used to create that namespace, then that name maps to the variable corresponding to that identifier. The mapping is undefined for other names.
+
+## Returns
+
+The name `NAME | "𝕊" | "𝕣"` in a `Return` node is resolved exactly like any other identifier. Following resolution, the block that defines the identifier must not be a namespace block (export variables or contain an `EXPORT` statement). Furthermore, if it is a `NAME`, then its definition must be an internal name for a containing block: `s` in `brSub`, `F` in `FuncHead` or `FMain`, `_m` in `Mod1H1` or `_mMain`, or `_c_` in `Mod2H1` or `_cMain_`. When reached, the `Return` node's identifier is not accessed; instead, it is used to indicate the namespace that contains it, and through this the block evaluation that created that namespace.