From acd2159e1778893ff9d97da1120fb0c6e43a6fc1 Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Sun, 31 Oct 2021 22:08:07 -0400 Subject: Specify that evaluation can fail due to insufficient resources (e.g. memory) --- docs/spec/evaluate.html | 1 + docs/spec/index.html | 1 + 2 files changed, 2 insertions(+) (limited to 'docs') 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 @@

This page describes the semantics of the code constructs whose grammar is given in grammar.md. 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.

Here we assume that the referent of each identifier, or equivalently the connections between identifiers, have been identified according to the scoping rules.

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.

A PROGRAM or BODY is a list of STMTs, which are evaluated in program order. A result is always required for BODY nodes, and sometimes for PROGRAM nodes (for example, when loaded with •Import). If any identifiers in the node's scope are exported, or any of its statements is an EXPORT, 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 STMT node must be an EXPR and its result is used. The statement EXPR evaluates some APL code and possibly assigns the results, while nothing evaluates any subject or Derv terms it contains but discards the results. An EXPORT statement performs no action.

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 @@
  • 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.
    • -- cgit v1.2.3