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

Editorial: add description to Function Environment Records #3401

Closed
wants to merge 1 commit into from

Conversation

OnlyWick
Copy link
Contributor

No description provided.

@jmdyck
Copy link
Collaborator

jmdyck commented Aug 25, 2024

This resolves an inconsistency in the paragraph (that goes back to ES6), but I wonder if it should have gone the other way (adding "function" to the first occurrence)...

The phrase "the function is [not] an |ArrowFunction|" is technically a category error, since a function is an Object (a language value), whereas an |ArrowFunction| is a Parse Node (a spec value). Saying "an |ArrowFunction| function" avoids the category error, but isn't much clearer, because the spec doesn't define what "an |ArrowFunction| function" is. I imagine it's a function that was created by evaluating an |ArrowFunction| expression. But if we expect readers to fill in that gap, then maybe it's okay to expect them to make sense of the category-error version.

@OnlyWick
Copy link
Contributor Author

@jmdyck You reminded me that function is an Object, which I didn't initially notice because I instinctively thought of ArrowFunction as a function type. That's why I considered the function word in an |ArrowFunction| function unnecessary. You mentioned that an |ArrowFunction| function can avoid a category error, so indeed, it would be better to include the word 'function' from the beginning, simply treating it as one of many types of functions.

@michaelficarra
Copy link
Member

It's not even correct, there's also AsyncArrowFunction now.

@OnlyWick
Copy link
Contributor Author

@michaelficarra Yeah, you're right. I can update it. :-)

15.3.4 Runtime Semantics: InstantiateArrowFunctionExpression
...
5. Let closure be OrdinaryFunctionCreate(%Function.prototype%, sourceText, ArrowParameters, ConciseBody, lexical-this, env, privateEnv).
...

15.9.4 Runtime Semantics: InstantiateAsyncArrowFunctionExpression
...
6. Let closure be OrdinaryFunctionCreate(%AsyncFunction.prototype, sourceText, parameters, AsyncConciseBody, lexical-this, env, privateEnv).
...

@OnlyWick OnlyWick force-pushed the remove-extra-word branch 2 times, most recently from f57b25e to c720771 Compare August 27, 2024 01:50
@OnlyWick
Copy link
Contributor Author

About this sentence: If a function is not an ArrowFunction function and references super, I need some time to explore whether it needs to include AsyncArrowFunction. lol

@OnlyWick OnlyWick changed the title Editorial: remove extra 'function' word Editorial: add description to Function Environment Records Aug 27, 2024
@OnlyWick
Copy link
Contributor Author

@michaelficarra And, [[ThisBindingStatus]]: If the value is lexical, this is an ArrowFunction and does not have a local this value. also missing AsyncArrowFunction. I will update it later.

@OnlyWick
Copy link
Contributor Author

OnlyWick commented Aug 27, 2024

If a function is not an |ArrowFunction| function and references super also missing AsyncArrowFunction.

The super Keyword RS: Evaluation and MakeSuperPropertyReference ( actualThis, propertyKey, strict ) always have below step,

  • Let env be GetThisEnvironment().

If use ArrowFunction or AsyncArrowFunction, it need to go through 9.4.3 GetThisEnvironment( ) find correct state.

@OnlyWick
Copy link
Contributor Author

Already update it, @jmdyck @michaelficarra Can you review it?

@OnlyWick OnlyWick closed this by deleting the head repository Nov 15, 2024
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

Successfully merging this pull request may close these issues.

3 participants