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

Normative: Add dynamic import() #1482

Merged
merged 1 commit into from Jun 15, 2019

Conversation

@littledan
Copy link
Member

commented Mar 16, 2019

This PR includes minor changes to rebase, which are out for
review in tc39/proposal-dynamic-import#72

Proposal author: Domenic Denicola

@ljharb

This comment has been minimized.

Copy link
Member

commented Mar 16, 2019

@ljharb ljharb requested review from ljharb, zenparsing and tc39/ecma262-editors Mar 16, 2019

Show resolved Hide resolved spec.html
<p>The intent of this specification is to not violate run to completion semantics. The spec-level formalization of this is a work-in-progress.</p>
</li>
<li>
Every call to HostImportModuleDynamically with the same _referencingScriptOrModule_ and _specifier_ arguments must conform to the <em>same</em> set of requirements above as previous calls do. That is, if the host environment takes the success path once for a given _referencingScriptOrModule_, _specifier_ pair, it must always do so, and the same for the failure path.

This comment has been minimized.

Copy link
@ljharb

ljharb Mar 16, 2019

Member

Does this also hold with a null referencingScriptOrModule? ie, is everything with null considered the same referencing module, or is it more like NaN where they’re all intended to be distinct?

This comment has been minimized.

Copy link
@littledan

littledan Mar 16, 2019

Author Member

Yes, it does hold. Do you think this is unclear in the text?

This comment has been minimized.

Copy link
@ljharb

ljharb Mar 16, 2019

Member

My reading is that for a given referencing location, two calls should be idempotent, but that one call from each of two different locations need not produce the same result.

This line suggests that one call from each of two different locations with null will always be required to have the same result - ie, it seems stricter on engines for when there’s no referencing location. The difference between the cases strikes me as odd; it seems like either the null case needs relaxing or the non-null case needs tightening, to make things more consistent?

This comment has been minimized.

Copy link
@littledan

littledan Mar 16, 2019

Author Member

Well, to explain how it works out in HTML (cc @domenic), if you are in one of these null contexts, then it's basically like you're in the context of the whole web page. So the base URL of the whole page is used to parse relative URLs. In this case, it does make sense to group together all the null imports.

I suspect it might work out similarly in other environments: When you don't have a clear referencing script, the context is something corresponding to the Realm. But it may be that there are other environments that need a weaker condition.

How about we start with this strong condition, and consider a follow-on needs-consensus PR to weaken the condition if an embedding environment comes along where this invariant needs to be relaxed? Stating as strong conditions as possible could keep things more predictable for ECMAScript itself.

This comment has been minimized.

Copy link
@ljharb

ljharb Mar 16, 2019

Member

Sounds good - if the intended usage in browsers is indeed to group all nulls as the same effective referencing script, then as-written seems fine to me.

spec.html Outdated
@@ -23295,6 +23394,10 @@ <h1>Forbidden Extensions</h1>
<li>
When parsing for the |Module| goal symbol, the lexical grammar extensions defined in <emu-xref href="#sec-html-like-comments"></emu-xref> must not be supported.
</li>
<li>
<ins>|ImportCall| must not be extended.</ins>
<!-- This is so that in the future we can potentially add new arguments or support ArgumentList. -->

This comment has been minimized.

Copy link
@ljharb

ljharb Mar 16, 2019

Member

Given this intended support, should a trailing comma be allowed in the grammar? (not an editor question, just a curious delegate question)

This comment has been minimized.

Copy link
@littledan

littledan Mar 16, 2019

Author Member

Hmm, I guess I have to say that, personally, I would expect a trailing comma to be allowed, not because of potential future extensions, but just because we allow trailing commas in ordinary calls. However, I think we should pursue this possible change in a separate needs-consensus PR, as the grammar in this proposal is already widely implemented and shipped, and it was promoted to Stage 3 with the interaction visible to the committee.

@ljharb ljharb self-assigned this Mar 16, 2019

Show resolved Hide resolved spec.html Outdated
spec.html Outdated
If a Module Record corresponding to the pair _referencingScriptOrModule_, _specifier_ does not exist or cannot be created, an exception must be thrown.
</li>
<li>
This operation must be idempotent if it completes normally. Each time it is called with a specific _referencingScriptOrModule_, _specifier_ pair as arguments it must return the same Module Record instance.

This comment has been minimized.

Copy link
@ljharb

ljharb Mar 20, 2019

Member

confirming; is "idempotent" the correct word here? cc @michaelficarra / #1133

This comment has been minimized.

Copy link
@michaelficarra

michaelficarra Mar 26, 2019

Member

I change the equivalent to this line to avoid the usage of "idempotent" this way in #1363. We'll need to resolve the conflict.

This comment has been minimized.

Copy link
@littledan

littledan Mar 26, 2019

Author Member

Any suggestions for the wording here?

This comment has been minimized.

Copy link
@devsnek

devsnek Mar 26, 2019

Member

This operation must be deterministic with respect to its parameters if it completes normally

This comment has been minimized.

Copy link
@littledan

littledan Mar 26, 2019

Author Member

Some embedding environments may do some I/O here, e.g., to get the module, so I don't think this would be accurate.

This comment has been minimized.

Copy link
@littledan

littledan Mar 26, 2019

Author Member

I just don't understand what the term "deterministic" would mean here. When I read that sentence, it makes me think that it's saying that the operation is a function of its parameters, which would not be the case.

This comment has been minimized.

Copy link
@michaelficarra

michaelficarra Mar 26, 2019

Member

@littledan It means that if I give you the same parameters in two separate calls to that function, it should produce the same result. If you'd prefer an alternative way to state that, you should comment on #1363.

This comment has been minimized.

Copy link
@allenwb

allenwb Mar 26, 2019

Member

I agree with @littledan. "deterministic" does not have that meaning. A deterministic function could have inputs other than its formal parameters, such as the phase of the moon, the load on the CPUI, or the load factor on a cache. It may well be "deterministic" what will happen in all those cases but that doesn't guarantee that successive calls with the specific argument will return the same result.

This comment has been minimized.

Copy link
@michaelficarra

michaelficarra Mar 26, 2019

Member

@allenwb That's why the phrase is "deterministic with respect to", to tell you what are the inputs for that determinism.

This comment has been minimized.

Copy link
@littledan

littledan Mar 26, 2019

Author Member

Let's move this discussion to #1363. I'll update this patch when we land it.

Show resolved Hide resolved spec.html
Show resolved Hide resolved spec.html Outdated
Show resolved Hide resolved spec.html Outdated
Show resolved Hide resolved spec.html
Show resolved Hide resolved spec.html Outdated
Show resolved Hide resolved spec.html
@littledan

This comment has been minimized.

Copy link
Member Author

commented Apr 26, 2019

Thanks @jmdyck , made the suggested fixes.

@aduh95 aduh95 referenced this pull request May 7, 2019

Closed

What's keeping this from stage 4? #75

4 of 5 tasks complete

@ljharb ljharb requested a review from jmdyck May 29, 2019

@jmdyck
Copy link
Collaborator

left a comment

I looked it over again, but don't have anything to add.

@ljharb

ljharb approved these changes Jun 6, 2019

Show resolved Hide resolved spec.html

@ljharb ljharb added has stage 4 and removed pending stage 4 labels Jun 6, 2019

@ljharb ljharb force-pushed the littledan:dynamic-import branch from 8947265 to f9df2e8 Jun 15, 2019

ljharb added a commit to littledan/ecma262 that referenced this pull request Jun 15, 2019

Normative: Add dynamic import() (tc39#1482)
This PR includes minor changes to rebase, which are out for
review in tc39/proposal-dynamic-import#72

Co-authored-by: Domenic Denicola <d@domenic.me>
Normative: Add dynamic import() (#1482)
This PR includes minor changes to rebase, which are out for
review in tc39/proposal-dynamic-import#72

Co-authored-by: Domenic Denicola <d@domenic.me>

@ljharb ljharb force-pushed the littledan:dynamic-import branch from f9df2e8 to 94c6f97 Jun 15, 2019

@ljharb ljharb merged commit 94c6f97 into tc39:master Jun 15, 2019

1 check was pending

continuous-integration/travis-ci/push The Travis CI build is in progress
Details

rkirsling added a commit to rkirsling/ecma262 that referenced this pull request Jun 16, 2019

ljharb added a commit to rkirsling/ecma262 that referenced this pull request Jun 16, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.