From 7de47f9a7db71a179ba3124d39cc2c5be2000fd4 Mon Sep 17 00:00:00 2001 From: Marshall Lochbaum Date: Sat, 16 Apr 2022 17:23:57 -0400 Subject: =?UTF-8?q?Specify=20ordering=20of=20destructuring=20=E2=86=A9=20w?= =?UTF-8?q?ith=20error=20catching?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/spec/evaluate.html | 1 + docs/spec/scope.html | 2 +- spec/evaluate.md | 2 ++ spec/scope.md | 2 +- 4 files changed, 5 insertions(+), 2 deletions(-) diff --git a/docs/spec/evaluate.html b/docs/spec/evaluate.html index c9c45110..9f00a28d 100644 --- a/docs/spec/evaluate.html +++ b/docs/spec/evaluate.html @@ -20,6 +20,7 @@

Assignment

An assignment is one of the four rules containing ASGN. It is evaluated by first evaluating the right-hand-side subExpr, FuncExpr, _m1Expr, or _m2Exp_ expression, and then storing the result in the left-hand-side identifier or identifiers. The result of the assignment expression is the result of its right-hand side. Except for subjects, only a lone identifier is allowed on the left-hand side and storage sets it equal to the result. For subjects, destructuring assignment is performed when an lhs is lhsList or lhsStr. Destructuring assignment is performed recursively by assigning right-hand-side values to the left-hand-side targets, with single-identifier assignment as the base case. The target "·" is also possible in place of a NAME, and performs no assignment.

The right-hand-side value, here called v, in destructuring assignment must be a list (rank 1 array) or namespace. If it's a list, then each LHS_ENTRY node must be an LHS_ELT. The left-hand side is treated as a list of lhs targets, and matched to v element-wise, with an error if the two lists differ in length. If v is a namespace, then the left-hand side must be an lhsStr where every LHS_ATOM is an NAME, or an lhsList where every LHS_ENTRY is an NAME or lhs "⇐" NAME, so that it can be considered a list of NAME nodes some of which are also associated with lhs nodes. To perform the assignment, the value of each name is obtained from the namespace v, giving an error if v does not define that name. The value is assigned to the lhs node if present (which may be a destructuring assignment or simple subject assignment), and otherwise assigned to the same NAME node used to get it from v.

+

A destructuring assignment is performed in program order, or equivalently index order, with each sub-assignment fully completed before beginning the next (a depth-first order). Thus if an assignment with ↩ encounters an error but it's caught with ⎊, some of the assignment may have already been performed, changing variable values.

Modified assignment is the subject assignment rule lhs Derv "↩" subExpr?. In this case, lhs is evaluated as if it were a subExpr (the syntax is a subset of subExpr), and passed as an argument to Derv. The full application is lhs Derv subExpr, if subExpr is given, and Derv lhs otherwise. Its value is assigned to lhs, and is also the result of the modified assignment expression.

Expressions

We now give rules for evaluating an atom, Func, _mod1 or _mod2_ expression (the possible options for ANY). A literal or primitive sl, Fl, _ml, or _cl_ has a fixed value defined by the specification (literals and built-ins). An identifier s, F, _m, or _c_, if not preceded by atom ".", 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 atom ".", then the atom 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 "(" _modExpr ")" simply returns the result of the interior expression. A braced construct such as BraceFunc is defined by the evaluation of the statements it contains after all parameters are accepted. Finally, a list "⟨" ⋄? ( ( EXPR ⋄ )* EXPR ⋄? )? "⟩" or ANY ( "‿" ANY )+ 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.

diff --git a/docs/spec/scope.html b/docs/spec/scope.html index f5e3e2c8..ef92f370 100644 --- a/docs/spec/scope.html +++ b/docs/spec/scope.html @@ -17,7 +17,7 @@
  • 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. 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. 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.

    Special names

    Special names such as 𝕩 or 𝕣 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.

    diff --git a/spec/evaluate.md b/spec/evaluate.md index e3b0c212..3a68a70a 100644 --- a/spec/evaluate.md +++ b/spec/evaluate.md @@ -32,6 +32,8 @@ An *assignment* is one of the four rules containing `ASGN`. It is evaluated by f The right-hand-side value, here called `v`, in destructuring assignment must be a list (rank 1 array) or namespace. If it's a list, then each `LHS_ENTRY` node must be an `LHS_ELT`. The left-hand side is treated as a list of `lhs` targets, and matched to `v` element-wise, with an error if the two lists differ in length. If `v` is a namespace, then the left-hand side must be an `lhsStr` where every `LHS_ATOM` is an `NAME`, or an `lhsList` where every `LHS_ENTRY` is an `NAME` or `lhs "⇐" NAME`, so that it can be considered a list of `NAME` nodes some of which are also associated with `lhs` nodes. To perform the assignment, the value of each name is obtained from the namespace `v`, giving an error if `v` does not define that name. The value is assigned to the `lhs` node if present (which may be a destructuring assignment or simple subject assignment), and otherwise assigned to the same `NAME` node used to get it from `v`. +A destructuring assignment is performed in program order, or equivalently index order, with each sub-assignment fully completed before beginning the next (a depth-first order). Thus if an assignment with `↩` encounters an error but it's caught with `⎊`, some of the assignment may have already been performed, changing variable values. + *Modified assignment* is the subject assignment rule `lhs Derv "↩" subExpr?`. In this case, `lhs` is evaluated as if it were a `subExpr` (the syntax is a subset of `subExpr`), and passed as an argument to `Derv`. The full application is `lhs Derv subExpr`, if `subExpr` is given, and `Derv lhs` otherwise. Its value is assigned to `lhs`, and is also the result of the modified assignment expression. ### Expressions 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. -- cgit v1.2.3