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

14.1.12 Static Semantics: IsFunctionDefinition #536

Closed
CountOrlok opened this issue Apr 12, 2016 · 2 comments · Fixed by tc39/ecmarkup#165
Closed

14.1.12 Static Semantics: IsFunctionDefinition #536

CountOrlok opened this issue Apr 12, 2016 · 2 comments · Fixed by tc39/ecmarkup#165
Labels
rendering bug A bug in the rendering of the spec on the web. spec bug

Comments

@CountOrlok
Copy link

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?

@GeorgNeis
Copy link
Contributor

I agree. (This also applies to classes and generator functions.)

@allenwb
Copy link
Member

allenwb commented Jun 7, 2016

Right, as noted in the original issue, this appears to be a regress from the original ES6. The bug also occurs in 14.4.9 and 14.5.8

@jmdyck jmdyck added the rendering bug A bug in the rendering of the spec on the web. label Oct 27, 2018
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
Labels
rendering bug A bug in the rendering of the spec on the web. spec bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants