Editorial: Correct variable terminology #1326
Conversation
|
The only other such usage of "variable" occurs in reference to Should that usage be fixed as well? |
TimothyGu
changed the title
TimothyGu
force-pushed
the
await-explanation
branch
from
8820542 to
95d4da9
Compare
|
@zenparsing Should be fixed. |
spec.html
Outdated
| @@ -29434,7 +29434,7 @@ <h1>Notation</h1> | |||
| A <em>MatchResult</em> is either a State or the special token ~failure~ that indicates that the match failed. | |||
| </li> | |||
| <li> | |||
| A <em>Continuation</em> procedure is an internal closure (i.e. an internal procedure with some arguments already bound to values) that takes one State argument and returns a MatchResult result. If an internal closure references variables which are bound in the function that creates the closure, the closure uses the values that these variables had at the time the closure was created. The Continuation attempts to match the remaining portion (specified by the closure's already-bound arguments) of the pattern against _Input_, starting at the intermediate state given by its State argument. If the match succeeds, the Continuation returns the final State that it reached; if the match fails, the Continuation returns ~failure~. | |||
| A <em>Continuation</em> procedure is an internal closure (i.e. an internal procedure with some arguments already bound to values) that takes one State argument and returns a MatchResult result. If an internal closure references aliases which are bound in the function that creates the closure, the closure uses the values that these aliases had at the time the closure was created. The Continuation attempts to match the remaining portion (specified by the closure's already-bound arguments) of the pattern against _Input_, starting at the intermediate state given by its State argument. If the match succeeds, the Continuation returns the final State that it reached; if the match fails, the Continuation returns ~failure~. | |||
There was a problem hiding this comment.
i'm confused; closures reference variables, how can they reference aliases?
There was a problem hiding this comment.
My understanding is that the "continuations" in that section aren't JS closures, and the bindings that they capture aren't JS variables. They are the EcmaSpeak "aliases" instead (e.g. Disjunction). Does that sound right?
There was a problem hiding this comment.
Precisely as @zenparsing said. See https://tc39.github.io/ecma262/#sec-algorithm-conventions, where “alias” is defined.
@allenwb do you have any insights?
There was a problem hiding this comment.
This paragraph dates back to the 3rd edition. At the time, the spec used the word "closure" only to denote a spec artifact (what we might now think of as a dynamic abstract operation), used to describe the semantics of RegExps, and not to describe the behavior of ES functions. (The spec started to use the term more generally in the 5th edition, but it still has that specific meaning within the RegExp semantics.)
The phrase "the function that creates the closure" compounds the confusion. It would probably help to change that occurrence of "function" to "algorithm".
There was a problem hiding this comment.
#1889 defined abstract closures formally, resolving this issue.
|
Still hoping for some clarification re #1326 (comment) |
ljharb
force-pushed
the
await-explanation
branch
from
95d4da9 to
9165688
Compare
The spec "variables" are not variables, but aliases as defined in 5.2 Algorithm Conventions.