Editorial: Merge FunctionAllocate and FunctionInitialize by jmdyck · Pull Request #1562 · tc39/ecma262

jmdyck · 2019-05-31T02:02:05Z

FunctionAllocate and FunctionInitialize are always invoked in tandem. Moreover, the division between them seems somewhat arbitrary. So, merge the two operations into one, called OrdinaryFunctionCreate.

(Yeah, it's got 7 parameters, but I'm pretty sure we can eliminate one of them in a future refactoring.)

The second commit is the main one; the others are prep and cleanup.

(Web IDL and HTML do not reference FunctionAllocate or FunctionInitialize.)

ljharb · 2019-05-31T03:25:09Z

spec.html

        1. Else, let _allocKind_ be `"normal"`.
-        1. Let _F_ be FunctionAllocate(_prototype_, _Strict_, _allocKind_).
-        1. Return FunctionInitialize(_F_, _kind_, _ParameterList_, _Body_, _Scope_).
+        1. Return ! OrdinaryFunctionCreate(_prototype_, _ParameterList_, _Body_, _allocKind_, _kind_, _Strict_, _Scope_).


Is there a reason you didn’t keep the same param order - prototype, strict, allocKind, and then the initialize args?

The resulting order didn't make sense to me.

At the least, strict seems to me like it should come before body and parameter list, since it determines how it’s parsed.

Maybe in the real world, but not in spec-world. In general, the spec can't even ask whether some code is strict until after it's been parsed. And anyhow, parsing is well in the past by the time this operation is called. A function's [[Strict]] value is only used to affect the creation of an "arguments" object, and how 'this' gets bound. (I think.)

(Moreover, #1563 eliminates the _Strict_ parameter, so its position in the parameter list may be a moot point.)

jmdyck · 2019-06-17T15:16:11Z

(force-pushed to resolve merge conflicts)

jmdyck · 2019-07-17T19:58:07Z

(force-pushed to resolve merge conflicts again)

spec.html

jmdyck · 2019-09-14T14:33:09Z

(force-pushed to resolve merge conflicts /3)

jmdyck · 2019-10-14T13:54:28Z

(force-pushed to resolve merge conflicts /4)

syg · 2019-10-16T18:58:29Z

spec.html

+            1. Let _realmF_ be the current Realm Record.
            1. Let _scope_ be _realmF_.[[GlobalEnv]].
-            1. Perform FunctionInitialize(_F_, ~Normal~, _parameters_, _body_, _scope_).
+            1. Let _F_ be ! OrdinaryFunctionCreate(_proto_, _parameters_, _body_, _kind_, ~Normal~, _scope_).


Nice cleanup here for _scope_.

spec.html

syg · 2019-10-16T19:24:05Z

spec.html

-      <h1>FunctionAllocate ( _functionPrototype_, _functionKind_ )</h1>
-      <p>The abstract operation FunctionAllocate requires the two arguments _functionPrototype_ and _functionKind_. FunctionAllocate performs the following steps:</p>
+    <emu-clause id="sec-ordinaryfunctioncreate" aoid="OrdinaryFunctionCreate" oldids="sec-functionallocate,sec-functioninitialize">
+      <h1>OrdinaryFunctionCreate ( _functionPrototype_, _ParameterList_, _Body_, _functionKind_, _kind_, _Scope_ )</h1>


It's unfortunate there's both a _kind_ and a _functionKind_. AFAICT the ~Method~ case of _kind_ doesn't do anything, and _kind_ is only used to determine the this scope lookup mode. I would prefer to pass that directly, i.e. a new _thisMode_ that's ~LexicalThis~ or ~NonLexicalThis~ and have the non-lexical case checked for strictness inside this AO.

@jmdyck WDYT?

Ah, currently _kind_ is still used to determine the allocation kind for non-constructibles. It's all rather circuitous logic in there. Do you plan to layer this on top of #1546, after which my suggestion above makes more sense?

Do you plan to layer this on top of #1546?

Well, if #1546 is accepted, then I'll resolve the resulting merge conflicts here, if that's what you mean.

I would prefer to pass that directly, i.e. a new _thisMode_ that's ~LexicalThis~ or ~NonLexicalThis~

Done! (modulo naming)

and have the non-lexical case checked for strictness inside this AO.

I wasn't sure what you meant by this.

@syg

The only effect of OrdinaryFunctionCreate's _kind_ parameter is on the [[ThisMode]] of the new function. And although _kind_ has three possible values (~Normal~, ~Method~, ~Arrow~), the only thing that matters is whether or not it's ~Arrow~. So replace it with parameter _thisMode_ that has two possible values: ~lexical-this~ and ~nonlexical-this~. Suggested by @syg in: tc39#1562 (comment)

jmdyck · 2019-10-24T19:47:33Z

Force-pushed to resolve merge conflicts, and also to add 2 commits.

spec.html

@syg

The only effect of OrdinaryFunctionCreate's _kind_ parameter is on the [[ThisMode]] of the new function. And although _kind_ has three possible values (~Normal~, ~Method~, ~Arrow~), the only thing that matters is whether or not it's ~Arrow~. So replace it with parameter _thisMode_ that has two possible values: ~lexical-this~ and ~non-lexical-this~. Suggested by @syg in: tc39#1562 (comment)

michaelficarra

LGTM. This will probably have lots of variable renaming conflicts with #1477.

syg

lgtm. Nice cleanup!

spec.html

FunctionAllocate() always returns a function object whose [[Realm]] is the current Realm Record.

FunctionAllocate and FunctionInitialize are always invoked in tandem. Moreover, the division between them seems somewhat arbitrary. So, merge the two operations into one, called OrdinaryFunctionCreate.

(This seems like a sensible order to me, at least.)

... specifically: - FunctionCreate - GeneratorFunctionCreate - AsyncGeneratorFunctionCreate - AsyncFunctionCreate After the refactorings of PR tc39#1546 and the prior commits in this PR, these have slimmed down to very thin wrappers around OrdinaryFunctionCreate. The only thing they hide is the choice of prototype; all their parameters are simply passed through. I don't think they provide a useful abstraction layer any more. In fact, I think they're kind of an obstacle. Any change in the interface of OrdinaryFunctionCreate would require a corresponding change to each of these operations, an unnecessary complication and possible inhibitor. Downstream specs: - ES Intl doesn't use any of these operations. - WebIDL doesn't use any of these operations. - HTML has one call to FunctionCreate.

) The only effect of OrdinaryFunctionCreate's _kind_ parameter is on the [[ThisMode]] of the new function. And although _kind_ has three possible values (~Normal~, ~Method~, ~Arrow~), the only thing that matters is whether or not it's ~Arrow~. So replace it with parameter _thisMode_ that has two possible values: ~lexical-this~ and ~non-lexical-this~. Suggested in: tc39#1562 (comment)

jmdyck · 2019-11-14T21:13:50Z

Yay! Thanks for the merge.

In the ECMAScript spec, the recently merged [PR whatwg#1562](tc39/ecma262#1562) replaced the `FunctionCreate` operation (and some others) with the new operation `OrdinaryFunctionCreate`. This commit makes the necessary changes to HTML's only call to `FunctionCreate`.

Follows tc39/ecma262#1562.

jmdyck added the editorial change label May 31, 2019

ljharb reviewed May 31, 2019

View reviewed changes

ljharb requested review from a team and zenparsing May 31, 2019 03:30

jmdyck mentioned this pull request May 31, 2019

Editorial: Centralize strictness-determination for function definitions #1563

Merged

jmdyck force-pushed the OrdinaryFunctionCreate branch from 7cd5329 to 1dc95e2 Compare June 17, 2019 15:15

jmdyck force-pushed the OrdinaryFunctionCreate branch from 1dc95e2 to b284baf Compare July 17, 2019 19:57

ljharb reviewed Jul 17, 2019

View reviewed changes

spec.html Outdated Show resolved Hide resolved

ljharb approved these changes Jul 17, 2019

View reviewed changes

ljharb requested a review from a team July 17, 2019 22:22

jmdyck force-pushed the OrdinaryFunctionCreate branch from b284baf to c28a7bb Compare September 14, 2019 14:32

ljharb self-assigned this Sep 14, 2019

ljharb requested review from syg and removed request for a team and zenparsing October 9, 2019 22:16

jmdyck force-pushed the OrdinaryFunctionCreate branch from c28a7bb to a8cac86 Compare October 14, 2019 13:53

syg requested changes Oct 16, 2019

View reviewed changes

jmdyck force-pushed the OrdinaryFunctionCreate branch from a8cac86 to b30238b Compare October 24, 2019 19:46

ljharb reviewed Oct 24, 2019

View reviewed changes

spec.html Outdated Show resolved Hide resolved

ljharb requested a review from syg October 24, 2019 22:01

jmdyck force-pushed the OrdinaryFunctionCreate branch from b30238b to 324cc1c Compare October 24, 2019 23:24

michaelficarra approved these changes Oct 25, 2019

View reviewed changes

michaelficarra requested a review from bakkot November 1, 2019 19:24

syg approved these changes Nov 13, 2019

View reviewed changes

spec.html Show resolved Hide resolved

bakkot approved these changes Nov 13, 2019

View reviewed changes

jmdyck added 5 commits November 13, 2019 21:49

Editorial: small refactor in CreateDynamicFunction (tc39#1562)

d7ed312

FunctionAllocate() always returns a function object whose [[Realm]] is the current Realm Record.

Editorial: Merge FunctionAllocate and FunctionInitialize (tc39#1562)

604ed65

FunctionAllocate and FunctionInitialize are always invoked in tandem. Moreover, the division between them seems somewhat arbitrary. So, merge the two operations into one, called OrdinaryFunctionCreate.

Editorial: reorder steps of OrdinaryFunctionCreate (tc39#1562)

150dcc2

(This seems like a sensible order to me, at least.)

ljharb force-pushed the OrdinaryFunctionCreate branch from 324cc1c to 3899f59 Compare November 14, 2019 05:50

ljharb merged commit 3899f59 into tc39:master Nov 14, 2019

jmdyck deleted the OrdinaryFunctionCreate branch November 14, 2019 21:13

jmdyck mentioned this pull request Nov 15, 2019

Replace 'FunctionCreate' with 'OrdinaryFunctionCreate' whatwg/html#5086

Merged

nicolo-ribaudo mentioned this pull request Dec 18, 2019

Reorder strict=true and privateScope to follow FunctionCreate signature tc39/proposal-class-fields#282

Closed

domenic pushed a commit to whatwg/html that referenced this pull request Dec 19, 2019

Replace FunctionCreate with OrdinaryFunctionCreate

5b42943

Follows tc39/ecma262#1562.

Conversation

jmdyck commented May 31, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jmdyck commented Jun 17, 2019

Uh oh!

jmdyck commented Jul 17, 2019

Uh oh!

Uh oh!

jmdyck commented Sep 14, 2019

Uh oh!

jmdyck commented Oct 14, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jmdyck Oct 17, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jmdyck commented Oct 24, 2019

Uh oh!

Uh oh!

michaelficarra left a comment

Choose a reason for hiding this comment

Uh oh!

syg left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jmdyck commented Nov 14, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jmdyck Oct 17, 2019 •

edited

Loading