Specify that evaluation can fail due to insufficient resources (e.g. memory)

2 files changed, 2 insertions, 0 deletions

diff --git a/docs/spec/evaluate.html b/docs/spec/evaluate.html
index 888ae4f6..82ea88a2 100644
--- a/docs/spec/evaluate.html
+++ b/docs/spec/evaluate.html
@@ -8,6 +8,7 @@
 <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>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>
+<p>As specified, BQN programs can involve an arbitrary amount of information, but when run there will be memory and possibly other limitations. To accommodate this, any part of evaluation can cause an error, if a resource such as memory, stack memory, or limited execution time is exhausted.</p>
 <h3 id="programs-and-blocks"><a class="header" href="#programs-and-blocks">Programs and blocks</a></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>
diff --git a/docs/spec/index.html b/docs/spec/index.html
index 13d9afb7..80209ac7 100644
--- a/docs/spec/index.html
+++ b/docs/spec/index.html
@@ -28,5 +28,6 @@
 <li>If the specification does not identify the fill element for an array, then any or no fill can be deterministically chosen.</li>
 <li>If an expression in a program cannot be evaluated without error (that is, there is no context that would cause the program, or a caller with access to its result, to evaluate the expression but not eventually fail with an error), then the implementation may reject this program, giving an error before evaluating any code and regardless of context—in this case, it must not accept the program in any context. This &quot;compiler clause&quot; modifies the behavior described above.</li>
 <li>The way the program's output (either a result or an error) is displayed to the user is not specified.</li>
+<li>Evaluation can fail at any time if the implementation runs out of resources such as memory or stack space.</li>
 <li>Any system values can be implemented, and they may act in an arbitrary way including modifying the behavior of the rest of the program. System values can create values with types not included in the specification, whose behavior is left up to the implementation. If system values with names given in this specification are implemented, however, then they must conform with the specified behavior.</li>
 </ul>