Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What does [Yield, Await] mean in ECMA262 documentation? #1872

Closed
moonformeli opened this issue Feb 17, 2020 · 3 comments
Closed

What does [Yield, Await] mean in ECMA262 documentation? #1872

moonformeli opened this issue Feb 17, 2020 · 3 comments

Comments

@moonformeli
Copy link

moonformeli commented Feb 17, 2020

The documentation is clear and easy to understand, mostly. However, some sections are quite hard to understand for me because of some signs that I can't guess their meaning.

For example,
image

GeneratorMethod[Yield, Await]:
  * PropertyName[?Yield, ?Await] (UniqueFormalParameters[+Yield, ~Await] ) {
    GeneartorBody
  }

In this example, what does Yield, Await or Default mean and what are those + and ~ signs for?

@loganfsmyth
Copy link
Contributor

The meaning of these is specified in 5.1.5 Grammar Notation, part way down where it states

A production may be parameterized by a subscripted annotation of the form “[parameters]”

and further down it talks about the +, ~ and ? annotations.

@moonformeli
Copy link
Author

Thank you, I'll read that part and try to grasp what it explains

@bakkot
Copy link
Contributor

bakkot commented Feb 17, 2020

To summarize, these are called parameters (or sometimes, in other documents, flags), and they can appear in three places:

  1. When they appear to the right of the LHS nonterminal of a grammar production, that indicates this production takes those parameters, and they will be unprefixed
  2. When they appear to the right of one of the RHS nonterminals, they will be prefixed with ?, +, or ~:
    1. a ? prefix means that this should be provided the same variant of the parameter as the LHS was (e.g. the first ?Yield in the first production in your screenshot indicates that the PropertyName should be parsed using the same variant of the Yield parameter as the GeneratorMethod is being parsed with)
    2. a + prefix means that this nonterminal should be provided the positive variant of the parameter (e.g. the first +Yield in your screenshot indicates that UniqueFormalParameters should be parsed with the positive variant of that parameter)
    3. a ~ prefix means that this terminal should should be provided the negative variant of the parameter (e.g. the first -Await in your screenshot indicates that UniqueFormalParameters should be parsed with the negative variant of that parameter)
  3. When they appear to the left of one of the RHS productions, they will be prefixed with + or ~:
    1. a + prefix indicates that this production alternative is only available when the positive variant of the parameter was provided to the LHS (e.g. the [+Yield] to the left of YieldExpression in this section indicates that the YieldExpression production is only available when parsing AssignmentExpression using the positive variant of the Yield flag)
    2. a ~ prefix indicates that this production alternative is only available when the negative variant of the parameter was provided to the LHS (e.g. the [-Yield] to the left of the yield in this section indicates that the yield production is only available when parsing IdentifierReference using the negative variant of the Yield flag)

For a concrete example, a regular FunctionExpression has a FunctionBody which is parsed using the negative variant (or absence) of the yield parameter per 2.iii, which is threaded through the parsing of Statement, ExpressionStatement and ultimately AssignmentExpression per 1 and 2.i, which means that AssignmentExpression is parsed using the negative variant of the yield parameter, which means that per 3.ii you cannot have a YieldExpression in a regular FunctionExpression. (But you can have a yield as an IdentifierReference per 3.i.)

By contrast, a regular GeneratorExpression has a FunctionBody (via GeneratorBody) which is parsed using the positive variant (or presence) of the yield parameter per 2.ii, which means that you can have a YieldExpression in a GeneratorExpression, but you cannot have a yield as an IdentifierReference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants