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

2 files changed, 3 insertions, 0 deletions

diff --git a/spec/README.md b/spec/README.md
index 5a5c02b2..191116fa 100644
--- a/spec/README.md
+++ b/spec/README.md
@@ -25,4 +25,5 @@ In several cases, an implementation can choose between more than one possible be
 - If the specification does not identify the fill element for an array, then any or no fill can be deterministically chosen.
 - 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 "compiler clause" modifies the behavior described above.
 - The way the program's output (either a result or an error) is displayed to the user is not specified.
+- Evaluation can fail at any time if the implementation runs out of resources such as memory or stack space.
 - 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.
diff --git a/spec/evaluate.md b/spec/evaluate.md
index 12f55332..dccf902d 100644
--- a/spec/evaluate.md
+++ b/spec/evaluate.md
@@ -8,6 +8,8 @@ Here we assume that the referent of each identifier, or equivalently the connect
 
 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).
 
+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.
+
 ### Programs and blocks
 
 The result of parsing a valid BQN program is a `PROGRAM`, and the program is run by evaluating this term.