-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
14.1.12 Static Semantics: IsFunctionDefinition #536
Labels
Comments
I agree. (This also applies to classes and generator functions.) |
jmdyck
added a commit
to jmdyck/ecmarkup
that referenced
this issue
Dec 17, 2019
In practice, an `<emu-mods>` contains an `<emu-params>` and/or an `<emu-opt>`. My guess is that this rule was introduced with only `<emu-params>` in mind, as there are situations in which you might reasonably want to suppress the display of `<emu-params>`, but you should never suppress an `<emu-opt>`. --- An alternative to removing the rule (and, if my above guess is correct, a solution that would be more in line with the original intent) would be to change its selector from: `emu-production[collapsed] emu-mods` to: `emu-production[collapsed] emu-params` I.e., in a collapsed production, suppress the display of *only* the grammatical parameters (GPs). However, I didn't propose that solution because it's incomplete in 3 ways: - It doesn't suppress GPs in all contexts where we want to suppress them. (Generally we want to suppress GPs in any non-defining production, which includes all the collapsed production, but also includes lots of non-collapsed productions.) - It doesn't suppress all the annotations we typically want to suppress (e.g. lookahead restrictions and no-LineTerminator-here annotations) because those don't occur in `<emu-mods>`. - It doesn't allow for the rare cases where we *don't* want to suppress GPs (and annotations). Instead (in ecma262 at least), we explicitly remove unnecessary GPs and annotations from all productions where we don't want them to appear. (Note that this also has the benefit of making the source easier to read.) So even with the suggested modification, the rule would be basically pointless. Better to just delete it. --- This resolves issue tc39#108, and also: - tc39/ecma262#536 - tc39/ecma262#908 - tc39/ecma262#1139 - tc39/ecma262#1663
ljharb
pushed a commit
to jmdyck/ecmarkup
that referenced
this issue
Jan 17, 2020
In practice, an `<emu-mods>` contains an `<emu-params>` and/or an `<emu-opt>`. My guess is that this rule was introduced with only `<emu-params>` in mind, as there are situations in which you might reasonably want to suppress the display of `<emu-params>`, but you should never suppress an `<emu-opt>`. --- An alternative to removing the rule (and, if my above guess is correct, a solution that would be more in line with the original intent) would be to change its selector from: `emu-production[collapsed] emu-mods` to: `emu-production[collapsed] emu-params` I.e., in a collapsed production, suppress the display of *only* the grammatical parameters (GPs). However, I didn't propose that solution because it's incomplete in 3 ways: - It doesn't suppress GPs in all contexts where we want to suppress them. (Generally we want to suppress GPs in any non-defining production, which includes all the collapsed production, but also includes lots of non-collapsed productions.) - It doesn't suppress all the annotations we typically want to suppress (e.g. lookahead restrictions and no-LineTerminator-here annotations) because those don't occur in `<emu-mods>`. - It doesn't allow for the rare cases where we *don't* want to suppress GPs (and annotations). Instead (in ecma262 at least), we explicitly remove unnecessary GPs and annotations from all productions where we don't want them to appear. (Note that this also has the benefit of making the source easier to read.) So even with the suggested modification, the rule would be basically pointless. Better to just delete it. --- This resolves issue tc39#108, and also: - tc39/ecma262#536 - tc39/ecma262#908 - tc39/ecma262#1139 - tc39/ecma262#1663
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I think there is something missing in IsFunctionDefinition at 14.1.12. The operation as described here will only return true if the given production is a named function definition, but false for anonymous function definitions.
Therefore when calling IsAnonymousFunctionDefinition with argument production, the first algorithm step would always return false for anonymous function expressions and the operation HasName would be unreachable.
So it rather should be:
14.1.12 Static Semantics: IsFunctionDefinition
FunctionExpression: function (FormalParameters) {FunctionBody}
FunctionExpression: function BindingIdentifier (FormalParameters) {FunctionBody}
Return true.
[as in ES2015: IsFunctionDefiniton]
Or is there a reason for changing this?
The text was updated successfully, but these errors were encountered: