Skip to content

Conversation

@linclark
Copy link
Member

The terminology between WebAssembly and ES modules differs when it comes to instantiation, which causes some confusion for the integration of the two systems. Ideally, we wouldn't use the same term to mean two different things between the specs.

After talking about it with multiple people, it seems like calling it "the linking phase" might be a better name for this phase anyway. Developers are often confused about what actually happens during instantiation and why it's separated from evaluation. I believe "linking" more clearly communicates the justification for this being its own phase.

Note: This depends on #1311. The relevant commit for this PR is the last one. Once #1311 is merged, I can rebase this to remove those commits.

Copy link
Member

@devsnek devsnek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't speak for the spec changes themselves but the name change is great 👍

@annevk
Copy link
Member

annevk commented Sep 24, 2018

If this change is made, it would also require downstream changes, e.g., to https://html.spec.whatwg.org/.

cc @domenic

@allenwb
Copy link
Member

allenwb commented Sep 24, 2018

I also like this name change.

@dherman
Copy link
Member

dherman commented Sep 27, 2018

I've always been a fan of Legend of Zelda. 👍

spec.html Outdated
<p>A <dfn>Module Record</dfn> encapsulates structural information about the imports and exports of a single module. This information is used to link the imports and exports of sets of connected modules. A Module Record includes four fields that are only used when evaluating a module.</p>
<p>For specification purposes Module Record values are values of the Record specification type and can be thought of as existing in a simple object-oriented hierarchy where Module Record is an abstract class with concrete subclasses. This specification only defines a single Module Record concrete subclass named Source Text Module Record. Other specifications and implementations may define additional Module Record subclasses corresponding to alternative module definition facilities that they defined.</p>
<p>Module Record defines the fields listed in <emu-xref href="#table-36"></emu-xref>. All Module Definition subclasses include at least those fields. Module Record also defines the abstract method list in <emu-xref href="#table-37"></emu-xref>. All Module definition subclasses must provide concrete implementations of these abstract methods.</p>
<p>For specification purposes Module Record values are values of the Record specification type and can be thought of as existing in a simple object-oriented hierarchy where Module Record is an abstract class with both abstract and concrete subclasses. This specification defines the abstract subclass named Cyclic Module Record and its concrete subclass named Source Text Module Record. Other specifications and implementations may define additional Module Record subclasses corresponding to alternative module definition facilities that they defined.</p> <p>Module Record defines the fields listed in <emu-xref href="#table-36"></emu-xref>. All Module Definition subclasses include at least those fields. Module Record also defines the abstract method list in <emu-xref href="#table-37"></emu-xref>. All Module definition subclasses must provide concrete implementations of these abstract methods.</p>

This comment was marked as resolved.

@littledan
Copy link
Member

The name change seems good to me; I'm happy to see the positive reaction here. Let's discuss this in the November 2018 TC39 meeting.

@domenic
Copy link
Member

domenic commented Oct 18, 2018

I was hoping we could land layering changes outside of plenary?

@littledan
Copy link
Member

Oh, sure, I'd be fine with landing this outside of plenary. Let's just not delay this longer than that.

Editors, what do you think?

@bterlson
Copy link
Member

We're fine with this change; will finish reviewing #1311 and will pull these in together.

@ljharb ljharb requested review from a team and bmeck October 24, 2018 19:20
Copy link
Member

@ljharb ljharb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The diff for just the rename can be viewed here: linclark/ecma262@cyclic-mr-2...linclark:rename-instantiate

@littledan littledan added the has consensus This has committee consensus. label Feb 7, 2019
@ljharb ljharb requested review from a team and zenparsing and removed request for bterlson February 28, 2019 19:56
@littledan
Copy link
Member

Ping on this change; I was hoping it would be pulled in together with #1311 per #1312 (comment) .

@ljharb
Copy link
Member

ljharb commented Mar 3, 2019

@littledan this one won't be in 2019, and it'll need to be rebased as well (that will also help it be more easily reviewed, since it wasn't set up as a stacked PR)

@littledan
Copy link
Member

Rebase out for review at #1465 . Please let me know if you need anything else.

@ljharb
Copy link
Member

ljharb commented Mar 3, 2019

To clarify, please do not open redundant PRs; either the PR author has to rebase it, or you can post a link to your branch, and this PR can updated by an editor with those commits.

@littledan littledan force-pushed the rename-instantiate branch from c910453 to b7ba2f8 Compare March 4, 2019 08:51
@littledan
Copy link
Member

Oops, didn't realize I had write access to this branch. Rebased here.

Copy link
Member

@zenparsing zenparsing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good, and in general I like the name change. I'm curious about the churn that it might create for JS engine APIs, though.

Thoughts @ajklein? Other implementers?

@ajklein
Copy link
Contributor

ajklein commented Mar 4, 2019

I like the name change conceptually, so happy to see this move forward. I don't think that we'd change V8's C++ naming just because of this spec change; rather we'd use the new name if we had other reasons that the API needed changing. @GeorgNeis in case he agrees or disagrees

@littledan
Copy link
Member

Do you need anything else from me to review this patch? From #1312 (comment) , it sounds like implementation burden isn't a big issue here.

@ljharb ljharb removed the request for review from bmeck March 16, 2019 07:11
@ljharb ljharb force-pushed the rename-instantiate branch from 2cbf848 to 4f13bc9 Compare April 12, 2019 21:59
ljharb pushed a commit to linclark/ecma262 that referenced this pull request Apr 12, 2019
The terminology between WebAssembly and ES modules differs when it comes to
instantiation, which causes some confusion for the integration of the two
systems. Ideally, we wouldn't use the same term to mean two different things
between the specs.

After talking about it with multiple people, it seems like calling it "the
linking phase" might be a better name for this phase anyway. Developers
are often confused about what actually happens during instantiation and
why it's separated from evaluation. I believe "linking" more clearly
communicates the justification for this being its own phase.
@ljharb ljharb requested review from a team and zenparsing April 12, 2019 21:59
@ljharb ljharb self-assigned this Jun 3, 2019
The terminology between WebAssembly and ES modules differs when it comes to
instantiation, which causes some confusion for the integration of the two
systems. Ideally, we wouldn't use the same term to mean two different things
between the specs.

After talking about it with multiple people, it seems like calling it "the
linking phase" might be a better name for this phase anyway. Developers
are often confused about what actually happens during instantiation and
why it's separated from evaluation. I believe "linking" more clearly
communicates the justification for this being its own phase.
@ljharb ljharb force-pushed the rename-instantiate branch from 4f13bc9 to 05c7620 Compare June 3, 2019 20:41
@ljharb ljharb merged commit 05c7620 into tc39:master Jun 3, 2019
@Ms2ger
Copy link
Contributor

Ms2ger commented Jun 4, 2019

Is someone following up with other specs that currently use "Instantiate"? I'm thinking at least HTML, WebIDL, top-level-await and wasm/esm-integration.

@littledan
Copy link
Member

@Ms2ger I haven't done this yet; if you are interested in fixing these other specs, it would be greatly appreciated.

Ms2ger added a commit to whatwg/html that referenced this pull request Jun 25, 2019
Ms2ger added a commit to whatwg/webidl that referenced this pull request Jun 25, 2019
Ms2ger added a commit to Ms2ger/esm-integration that referenced this pull request Jun 25, 2019
littledan pushed a commit to WebAssembly/esm-integration that referenced this pull request Jun 25, 2019
* Update to current TLA draft.

* Rename uninstantiated to unlinked.

See <tc39/ecma262#1312>.
Ms2ger added a commit to whatwg/webidl that referenced this pull request Jun 26, 2019
domenic pushed a commit to whatwg/html that referenced this pull request Jul 2, 2019
xtuc pushed a commit to xtuc/esm-integration that referenced this pull request Aug 13, 2019
* Update to current TLA draft.

* Rename uninstantiated to unlinked.

See <tc39/ecma262#1312>.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

editorial change has consensus This has committee consensus.

Projects

None yet

Development

Successfully merging this pull request may close these issues.