aboutsummaryrefslogtreecommitdiff
path: root/docs/spec
diff options
context:
space:
mode:
Diffstat (limited to 'docs/spec')
-rw-r--r--docs/spec/evaluate.html5
-rw-r--r--docs/spec/grammar.html10
-rw-r--r--docs/spec/index.html2
-rw-r--r--docs/spec/scope.html3
4 files changed, 13 insertions, 7 deletions
diff --git a/docs/spec/evaluate.html b/docs/spec/evaluate.html
index 9e221c53..6fdf0a0f 100644
--- a/docs/spec/evaluate.html
+++ b/docs/spec/evaluate.html
@@ -7,12 +7,12 @@
<h1 id="specification-bqn-evaluation">Specification: BQN evaluation</h1>
<p>This page describes the semantics of the code constructs whose grammar is given in <a href="grammar.html">grammar.md</a>. The formation rules there are not named, and here they are identified by either the name of the term or by copying the rule entirely if there are several alternative productions.</p>
<p>Here we assume that the referent of each identifier, or equivalently the connections between identifiers, have been identified according to the <a href="scope.html">scoping rules</a>.</p>
-<p>Errors described in this page are &quot;evaluation errors&quot; and can be caught by the Catch (<code><span class='Modifier2'>⎊</span></code>) 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.</p>
+<p>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 <code><span class='Gets'>β†’</span></code>) from a block. Errors described in this page are &quot;evaluation errors&quot; and can be caught by the Catch (<code><span class='Modifier2'>⎊</span></code>) 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).</p>
<h3 id="programs-and-blocks">Programs and blocks</h3>
<p>The result of parsing a valid BQN program is a <code><span class='Function'>PROGRAM</span></code>, and the program is run by evaluating this term.</p>
<p>A <code><span class='Function'>PROGRAM</span></code> or <code><span class='Function'>BODY</span></code> is a list of <code><span class='Function'>STMT</span></code>s, which are evaluated in program order. A result is always required for <code><span class='Function'>BODY</span></code> nodes, and sometimes for <code><span class='Function'>PROGRAM</span></code> nodes (for example, when loaded with <code><span class='Function'>β€’Import</span></code>). If any identifiers in the node's scope are exported, or any of its statements is an <code><span class='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><span class='Function'>STMT</span></code> node must be an <code><span class='Function'>EXPR</span></code> and its result is used. The statement <code><span class='Function'>EXPR</span></code> evaluates some APL code and possibly assigns the results, while <code><span class='Value'>nothing</span></code> evaluates any <code><span class='Value'>subject</span></code> or <code><span class='Function'>Derv</span></code> terms it contains but discards the results. An <code><span class='Function'>EXPORT</span></code> statement performs no action.</p>
<p>A block consists of several <code><span class='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><span class='Value'>brImm</span></code> can only have one <code><span class='Function'>BODY</span></code>, and is evaluated by evaluating the code in it. Other types of blocks do not evaluate any <code><span class='Function'>BODY</span></code> immediately, but instead return a function or modifier that obtains its result by evaluating a particular <code><span class='Function'>BODY</span></code>. The <code><span class='Function'>BODY</span></code> 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 <code><span class='Function'>BODY</span></code> term, if the <code><span class='Function'>BODY</span></code> contains the special names <code><span class='Value'>𝕨𝕩𝕀</span><span class='Function'>π•Žπ•π•Š</span></code>, or if its header specifies arguments (the header-body combination is a <code><span class='Modifier'>_mCase</span></code> or <code><span class='Modifier2'>_cCase_</span></code>). Otherwise only one is required.</p>
-<p>To evaluate a block when enough inputs have been received, first the correct case must be identified. To do this, first each special case (<code><span class='Function'>FCase</span></code>, <code><span class='Modifier'>_mCase</span></code>, or <code><span class='Modifier2'>_cCase_</span></code>), excluding <code><span class='Function'>FCase</span></code> nodes containing <code><span class='Function'>UndoHead</span></code>, is checked in order to see if its arguments are strucurally compatible with the given arguments. That is, is <code><span class='Value'>headW</span></code> is a <code><span class='Value'>subject</span></code>, there must be a left argument matching that structure, and if <code><span class='Value'>headX</span></code> is a <code><span class='Value'>subject</span></code>, the right argument must match that structure. This means that <code><span class='Value'>𝕨</span></code> 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 (<code><span class='Function'>FMain</span></code>, <code><span class='Modifier'>_mMain</span></code>, or <code><span class='Modifier2'>_cMain_</span></code>) 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.</p>
+<p>To evaluate a block when enough inputs have been received, first the correct case must be identified. To do this, first each special case (<code><span class='Function'>FCase</span></code>, <code><span class='Modifier'>_mCase</span></code>, or <code><span class='Modifier2'>_cCase_</span></code>), excluding <code><span class='Function'>FCase</span></code> nodes containing <code><span class='Function'>UndoHead</span></code>, is checked in order to see if its arguments are strucurally compatible with the given arguments. That is, is <code><span class='Value'>headW</span></code> is a <code><span class='Value'>subject</span></code>, there must be a left argument matching that structure, and if <code><span class='Value'>headX</span></code> is a <code><span class='Value'>subject</span></code>, the right argument must match that structure. This means that <code><span class='Value'>𝕨</span></code> 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 (<code><span class='Function'>FMain</span></code>, <code><span class='Modifier'>_mMain</span></code>, or <code><span class='Modifier2'>_cMain_</span></code>) 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.</p>
<p>The only remaining step before evaluating the <code><span class='Function'>BODY</span></code> is to bind the inputs and other names. Special names are always bound when applicable: <code><span class='Value'>𝕨𝕩𝕀</span></code> if arguments are used, <code><span class='Value'>𝕨</span></code> if there is a left argument, <code><span class='Value'>π•—π•˜</span></code> if operands are used, and <code><span class='Modifier'>_𝕣</span></code> and <code><span class='Modifier2'>_𝕣_</span></code> for modifiers and combinators, respectively. Any names in the header are also bound, allowing multiple assignment for arguments.</p>
<p>If there is no left argument, but the <code><span class='Function'>BODY</span></code> contains <code><span class='Value'>𝕨</span></code> at the top level, then it is conceptually re-parsed with <code><span class='Value'>𝕨</span></code> replaced by <code><span class='Nothing'>Β·</span></code> to give a monadic version before application; this modifies the syntax tree by replacing some instances of <code><span class='Value'>arg</span></code> with <code><span class='Value'>nothing</span></code>. However, it also causes an error if, in a function that is called with no left argument, <code><span class='Value'>𝕨</span></code> is used as an operand or list element, where <code><span class='Value'>nothing</span></code> is not allowed by the grammar. The same effect can also be achieved dynamically by treating <code><span class='Nothing'>Β·</span></code> as a value and checking for it during execution. If it is used as a left argument, then the function should instead be called with no left argument (and similarly in trains); it it is used as a right argument, then the function and its left argument are evaluated but rather than calling the function <code><span class='Nothing'>Β·</span></code> is &quot;returned&quot; immediately; and if it is used in another context then it causes an error.</p>
<h3 id="assignment">Assignment</h3>
@@ -21,6 +21,7 @@
<p><em>Modified assignment</em> is the subject assignment rule <code><span class='Value'>lhs</span> <span class='Function'>Derv</span> <span class='String'>&quot;↩&quot;</span> <span class='Value'>subExpr</span></code>. In this case, <code><span class='Value'>lhs</span></code> should be evaluated as if it were a <code><span class='Value'>subExpr</span></code> (the syntax is a subset of <code><span class='Value'>subExpr</span></code>), and the result of the function application <code><span class='Value'>lhs</span> <span class='Function'>Derv</span> <span class='Value'>subExpr</span></code> should be assigned to <code><span class='Value'>lhs</span></code>, and is also the result of the modified assignment expression.</p>
<h3 id="expressions">Expressions</h3>
<p>We now give rules for evaluating an <code><span class='Value'>atom</span></code>, <code><span class='Function'>Func</span></code>, <code><span class='Modifier'>_mod1</span></code> or <code><span class='Modifier2'>_mod2_</span></code> expression (the possible options for <code><span class='Function'>ANY</span></code>). A literal or primitive <code><span class='Value'>sl</span></code>, <code><span class='Function'>Fl</span></code>, <code><span class='Modifier'>_ml</span></code>, or <code><span class='Modifier2'>_cl_</span></code> has a fixed value defined by the specification (<a href="literal.html">literals</a> and <a href="primitive.html">built-ins</a>). An identifier <code><span class='Value'>s</span></code>, <code><span class='Function'>F</span></code>, <code><span class='Modifier'>_m</span></code>, or <code><span class='Modifier2'>_c_</span></code>, if not preceded by <code><span class='Value'>atom</span> <span class='String'>&quot;.&quot;</span></code>, 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 <code><span class='Value'>atom</span> <span class='String'>&quot;.&quot;</span></code>, then the <code><span class='Value'>atom</span></code> 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 <code><span class='String'>&quot;(&quot;</span> <span class='Modifier'>_modExpr</span> <span class='String'>&quot;)&quot;</span></code> simply returns the result of the interior expression. A braced construct such as <code><span class='Function'>BraceFunc</span></code> is defined by the evaluation of the statements it contains after all parameters are accepted. Finally, a list <code><span class='String'>&quot;⟨&quot;</span> <span class='Separator'>β‹„</span><span class='Value'>?</span> <span class='Paren'>(</span> <span class='Paren'>(</span> <span class='Function'>EXPR</span> <span class='Separator'>β‹„</span> <span class='Paren'>)</span><span class='Value'>*</span> <span class='Function'>EXPR</span> <span class='Separator'>β‹„</span><span class='Value'>?</span> <span class='Paren'>)</span><span class='Value'>?</span> <span class='String'>&quot;⟩&quot;</span></code> or <code><span class='Function'>ANY</span> <span class='Paren'>(</span> <span class='String'>&quot;β€Ώ&quot;</span> <span class='Function'>ANY</span> <span class='Paren'>)</span><span class='Function'>+</span></code> 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.</p>
+<p>A <code><span class='Function'>Return</span></code> node creates a return function. As <a href="scope.html#returns">discussed</a> 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 <code><span class='Value'>𝕨</span></code>. Otherwise, evaluation stops immediately, and resumes at the end of the block where it returns the right argument <code><span class='Value'>𝕩</span></code> from that block.</p>
<p>Rules in the table below are function and modifier evaluation.</p>
<table>
<thead>
diff --git a/docs/spec/grammar.html b/docs/spec/grammar.html
index 46509c05..9babde63 100644
--- a/docs/spec/grammar.html
+++ b/docs/spec/grammar.html
@@ -32,10 +32,12 @@
</span> <span class='Function'>|</span> <span class='Function'>Operand</span> <span class='Modifier2'>_mod2_</span> <span class='Comment'># Left partial application
</span> <span class='Function'>|</span> <span class='Modifier'>_m</span> <span class='Function'>ASGN</span> <span class='Modifier'>_m1Expr</span>
</pre>
-<p>Functions can be formed by fully applying modifiers or as trains. modifiers are left-associative, so that the left operand (<code><span class='Function'>Operand</span></code>) can include modifier applications but the right operand (<code><span class='Value'>subject</span> <span class='Function'>|</span> <span class='Function'>Func</span></code>) 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.</p>
+<p>Functions can be formed by fully applying modifiers, as trains, or with the return token <code><span class='Gets'>β†’</span></code>, which behaves syntactically like a 1-modifier whose operand must be an identifier. Modifiers are left-associative, so that the left operand (<code><span class='Function'>Operand</span></code>) can include modifier applications but the right operand (<code><span class='Value'>subject</span> <span class='Function'>|</span> <span class='Function'>Func</span></code>) 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.</p>
<pre><span class='Function'>Derv</span> <span class='Function'>=</span> <span class='Function'>Func</span>
<span class='Function'>|</span> <span class='Function'>Operand</span> <span class='Modifier'>_mod1</span>
<span class='Function'>|</span> <span class='Function'>Operand</span> <span class='Modifier2'>_mod2_</span> <span class='Paren'>(</span> <span class='Value'>subject</span> <span class='Function'>|</span> <span class='Function'>Func</span> <span class='Paren'>)</span>
+ <span class='Function'>|</span> <span class='Function'>Return</span>
+<span class='Function'>Return</span> <span class='Function'>=</span> <span class='Paren'>(</span> <span class='Function'>NAME</span> <span class='Function'>|</span> <span class='String'>&quot;π•Š&quot;</span> <span class='Function'>|</span> <span class='String'>&quot;𝕣&quot;</span> <span class='Paren'>)</span> <span class='String'>&quot;β†’&quot;</span>
<span class='Function'>Operand</span> <span class='Function'>=</span> <span class='Value'>subject</span>
<span class='Function'>|</span> <span class='Function'>Derv</span>
<span class='Function'>Fork</span> <span class='Function'>=</span> <span class='Function'>Derv</span>
@@ -51,11 +53,11 @@
<span class='Function'>|</span> <span class='Paren'>(</span> <span class='Value'>subject</span> <span class='Function'>|</span> <span class='Value'>nothing</span> <span class='Paren'>)</span><span class='Value'>?</span> <span class='Function'>Derv</span> <span class='Value'>arg</span>
<span class='Value'>nothing</span> <span class='Function'>=</span> <span class='String'>&quot;Β·&quot;</span>
<span class='Function'>|</span> <span class='Paren'>(</span> <span class='Value'>subject</span> <span class='Function'>|</span> <span class='Value'>nothing</span> <span class='Paren'>)</span><span class='Value'>?</span> <span class='Function'>Derv</span> <span class='Value'>nothing</span>
-<span class='Function'>LHS_NAME</span> <span class='Function'>=</span> <span class='Value'>s</span> <span class='Function'>|</span> <span class='Function'>F</span> <span class='Function'>|</span> <span class='Modifier'>_m</span> <span class='Function'>|</span> <span class='Modifier2'>_c_</span>
-<span class='Function'>LHS_ANY</span> <span class='Function'>=</span> <span class='Function'>LHS_NAME</span> <span class='Function'>|</span> <span class='Value'>lhsList</span>
+<span class='Function'>NAME</span> <span class='Function'>=</span> <span class='Value'>s</span> <span class='Function'>|</span> <span class='Function'>F</span> <span class='Function'>|</span> <span class='Modifier'>_m</span> <span class='Function'>|</span> <span class='Modifier2'>_c_</span>
+<span class='Function'>LHS_ANY</span> <span class='Function'>=</span> <span class='Function'>NAME</span> <span class='Function'>|</span> <span class='Value'>lhsList</span>
<span class='Function'>LHS_ATOM</span> <span class='Function'>=</span> <span class='Function'>LHS_ANY</span> <span class='Function'>|</span> <span class='String'>&quot;(&quot;</span> <span class='Value'>lhsStr</span> <span class='String'>&quot;)&quot;</span>
<span class='Function'>LHS_ELT</span> <span class='Function'>=</span> <span class='Function'>LHS_ANY</span> <span class='Function'>|</span> <span class='Value'>lhsStr</span>
-<span class='Function'>LHS_ENTRY=</span> <span class='Function'>LHS_ELT</span> <span class='Function'>|</span> <span class='Value'>lhs</span> <span class='String'>&quot;⇐&quot;</span> <span class='Function'>LHS_NAME</span>
+<span class='Function'>LHS_ENTRY=</span> <span class='Function'>LHS_ELT</span> <span class='Function'>|</span> <span class='Value'>lhs</span> <span class='String'>&quot;⇐&quot;</span> <span class='Function'>NAME</span>
<span class='Value'>lhsStr</span> <span class='Function'>=</span> <span class='Function'>LHS_ATOM</span> <span class='Paren'>(</span> <span class='String'>&quot;β€Ώ&quot;</span> <span class='Function'>LHS_ATOM</span> <span class='Paren'>)</span><span class='Function'>+</span>
<span class='Value'>lhsList</span> <span class='Function'>=</span> <span class='String'>&quot;⟨&quot;</span> <span class='Separator'>β‹„</span><span class='Value'>?</span> <span class='Paren'>(</span> <span class='Paren'>(</span> <span class='Function'>LHS_ENTRY</span> <span class='Separator'>β‹„</span> <span class='Paren'>)</span><span class='Value'>*</span> <span class='Function'>LHS_ENTRY</span> <span class='Separator'>β‹„</span><span class='Value'>?</span> <span class='Paren'>)</span><span class='Value'>?</span> <span class='String'>&quot;⟩&quot;</span>
<span class='Value'>lhs</span> <span class='Function'>=</span> <span class='Value'>s</span> <span class='Function'>|</span> <span class='Value'>lhsList</span> <span class='Function'>|</span> <span class='Value'>lhsStr</span>
diff --git a/docs/spec/index.html b/docs/spec/index.html
index 3b5539ee..d1673dc6 100644
--- a/docs/spec/index.html
+++ b/docs/spec/index.html
@@ -5,7 +5,7 @@
</head>
<div class="nav"><a href="https://github.com/mlochbaum/BQN">BQN</a> / <a href="../index.html">main</a></div>
<h1 id="bqn-specification">BQN specification</h1>
-<p>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 <a href="../doc/index.html">documentation</a> 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.</p>
+<p>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 <a href="../doc/index.html">documentation</a> 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.</p>
<p>Under this specification, a language implementation is a <strong>BQN pre-version implementation</strong> if it behaves as specified for all input programs. It is a <strong>BQN pre-version implementation with extensions</strong> 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 <strong>partial</strong> 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.</p>
<p>The following documents are included in the BQN specification. A BQN program is a sequence of <a href="https://en.wikipedia.org/wiki/Unicode">Unicode</a> code points: to evaluate it, it is converted into a sequence of tokens using the token formation rules, then these tokens are arranged in a syntax tree according to the grammar, and then this tree is evaluated according to the evaluation semantics. The program may be evaluated in the presence of additional context such as a filesystem or command-line arguments; this context is presented to the program and manipulated through the system-provided values.</p>
<ul>
diff --git a/docs/spec/scope.html b/docs/spec/scope.html
index 8ed5bab2..8ab3fd91 100644
--- a/docs/spec/scope.html
+++ b/docs/spec/scope.html
@@ -18,6 +18,7 @@
</ul>
<p>The definition for an identifier is chosen from the potential definitions based on their containing scopes: it is the one whose containing scope does not contain or match the containing scope of any other potential definition. If for any identifier there is no definition, then the program is not valid and results in an error. This can occur if the identifier has no potential definition, and also if two potential definitions appear in the same scope. In fact, under this scheme it is never valid to make two definitions with the same name at the top level of a single scope, because both definitions would be potential definitions for the one that comes second in program order. Both definitions have the same containing scope, and any potential definition must contain or match this scope, so no potential definition can be selected.</p>
<p>The definition of <em>program order</em> for identifier tokens follows the order of BQN <a href="evaluate.html">execution</a>. 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 <code><span class='Function'>PROGRAM</span></code>, <code><span class='Function'>BODY</span></code>, <code><span class='Function'>NS_BODY</span></code>, <code><span class='Value'>list</span></code>, <code><span class='Value'>subject</span></code> (for stranding), and body case (<code><span class='Function'>FCase</span></code>, <code><span class='Modifier'>_mCase</span></code>, <code><span class='Modifier2'>_cCase_</span></code>, <code><span class='Function'>FMain</span></code>, <code><span class='Modifier'>_mMain</span></code>, <code><span class='Modifier2'>_cMain_</span></code>, <code><span class='Value'>brSub</span></code>, <code><span class='Function'>BrFunc</span></code>, <code><span class='Modifier'>_brMod1</span></code>, and <code><span class='Modifier2'>_brMod2_</span></code>) 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).</p>
+<p>A subject label is the <code><span class='Value'>s</span></code> term in a <code><span class='Value'>brSub</span></code> 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 <code><span class='Function'>Return</span></code> node (which cannot access its value).</p>
<h3 id="special-names">Special names</h3>
<p>Special names such as <code><span class='Value'>𝕩</span></code> or <code><span class='Value'>𝕣</span></code> 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.</p>
<p>The six special names are <code><span class='Value'>π•¨π•©π•—π•˜π•€π•£</span></code>, and the tokens <code><span class='Function'>π•Žπ•π”½π”Ύπ•Š</span></code>, <code><span class='Modifier'>_𝕣</span></code>, and <code><span class='Modifier2'>_𝕣_</span></code> are alternate spellings of these names as described in the <a href="token.html">tokenization rules</a>. Special names may be modified with <code><span class='Gets'>↩</span></code> assignment but cannot appear as the target of other kinds of assignment. Two special names represent the same identifier if they are the same name and appear in the same body. The initial value these names have is defined by the <a href="evaluate.html">evaluation rules</a>; the grammar for blocks ensures that all special names used in a block will be defined (possibly as the special value <code><span class='Nothing'>Β·</span></code> in the case of <code><span class='Value'>𝕨</span></code>).</p>
@@ -29,3 +30,5 @@
<p>When a body in a block is evaluated, it creates a <em>namespace</em>, which contains a variable for each definition (that is, defined identifier instance) the body contains. Whenever another blockβ€”the block itself, not its contentsβ€”is evaluated during the execution of the block, it is linked to the currently-evaluating block, so that it will use the variables defined in this instance. By following these links repeatedly, an instance of a block is always linked to exactly one instance of each block that contains it. These links form a tree that is not necessarily related to the call stack of functions and modifiers. Using the links, the variable an identifier refers to is the one corresponding to that variable's definition in the linked instance of the containing scope for the definition.</p>
<p>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.</p>
<p>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.</p>
+<h2 id="returns">Returns</h2>
+<p>The name <code><span class='Function'>NAME</span> <span class='Function'>|</span> <span class='String'>&quot;π•Š&quot;</span> <span class='Function'>|</span> <span class='String'>&quot;𝕣&quot;</span></code> in a <code><span class='Function'>Return</span></code> 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 <code><span class='Function'>EXPORT</span></code> statement). Furthermore, if it is a <code><span class='Function'>NAME</span></code>, then its definition must be an internal name for a containing block: <code><span class='Value'>s</span></code> in <code><span class='Value'>brSub</span></code>, <code><span class='Function'>F</span></code> in <code><span class='Function'>FuncHead</span></code> or <code><span class='Function'>FMain</span></code>, <code><span class='Modifier'>_m</span></code> in <code><span class='Function'>Mod1H1</span></code> or <code><span class='Modifier'>_mMain</span></code>, or <code><span class='Modifier2'>_c_</span></code> in <code><span class='Function'>Mod2H1</span></code> or <code><span class='Modifier2'>_cMain_</span></code>. When reached, the <code><span class='Function'>Return</span></code> 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.</p>