diff options
| author | Marshall Lochbaum <mwlochbaum@gmail.com> | 2022-04-16 17:23:57 -0400 |
|---|---|---|
| committer | Marshall Lochbaum <mwlochbaum@gmail.com> | 2022-04-16 17:23:57 -0400 |
| commit | 7de47f9a7db71a179ba3124d39cc2c5be2000fd4 (patch) | |
| tree | 6441aa12e97b011476f3aab36efc2c479adc9e13 /spec/scope.md | |
| parent | 987e6890f78e54402b1355201d45e2fbce1fd992 (diff) | |
Specify ordering of destructuring ↩ with error catching
Diffstat (limited to 'spec/scope.md')
| -rw-r--r-- | spec/scope.md | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/spec/scope.md b/spec/scope.md index 5c09bd1f..a5ffb38c 100644 --- a/spec/scope.md +++ b/spec/scope.md @@ -18,7 +18,7 @@ Two identifier instances have the *same name* if their tokens, as strings, match - The two identifiers are the same instance (a defined variable is its own definition). 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. -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`, `list`, `subject` (for stranding), and body structure (`I_CASE`, `A_CASE`, `IMM_BLK`, `ARG_BLK`, and `blSub`) 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). +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`, `list`, `subject` (for stranding), `lhsList`, `lhsStr`, and body structure (`I_CASE`, `A_CASE`, `IMM_BLK`, `ARG_BLK`, and `blSub`) nodes, in which program order goes in the opposite order, from left to right. A subject label is the `s` term in a `blSub` 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. |
