Re-exporting imports and CreateImportBinding assertions
# Adam Klein (10 years ago)
I've added this to a few bugs on the bug-tracker:
ecmascript#4184 (CreateImportBinding) ecmascript#4244 (GetExportedNames and ResolveExport)
I've added this to a few bugs on the bug-tracker: https://bugs.ecmascript.org/show_bug.cgi?id=4184 (CreateImportBinding) https://bugs.ecmascript.org/show_bug.cgi?id=4244 (GetExportedNames and ResolveExport) On Wed, Apr 1, 2015 at 4:31 PM, Adam Klein <adamk at chromium.org> wrote: > I have a question about CreateImportBinding(N, M, N2) (where N is the name > to create in the importing module, and M is a module which exports N2). > > Step 4 of > https://people.mozilla.org/~jorendorff/es6-draft.html#sec-createimportbinding > is the following assertion > > "Assert: When M.[[Environment]] is instantiated it will have a direct > binding for N2." > > What about the case were M is simply re-exporting an import? Consider: > > --------- > module 'a': > > import { x } from 'b'; > > --------- > module 'b': > > import { x } from 'c'; > export { x }; > > --------- > module 'c': > > export let x = 42; > > --------- > > In this case, when running CreateImportBinding(x, 'b', x) in module 'a', > the assertion fails, as x in 'b' is an "immutable indirect binding" (itself > created by CreateImportBinding). > > Is there a need for this assert I'm missing? I don't think skipping over > this assert, or removing "direct" from its wording, will cause any > problems. Also, the term "direct binding" is not defined anywhere that I > can find, except as the negation of the "indirect" binding created by > CreateImportBinding. > > Note that there's a similar issue in ResolveExport: step 4.a.i of > https://people.mozilla.org/~jorendorff/es6-draft.html#sec-resolveexport > asserts that resolved exports found in [[LocalExportEntries]] are "leaf > bindings" (another term that goes undefined), where by the usual CS > definition of "leaf" the assertion would be false for x in 'b' (when > resolved from 'a'). > > - Adam > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150402/0c73f1a7/attachment.html>
# Adam Klein (10 years ago)
And to close the loop: rev37 makes clear that ResolveExport() will follow re-exported import bindings to discover the module in which they originated. This makes all the assertions correct. In my example, it means that the CreateImportBinding call in 'a' is:
CreateImportBinding(x, 'c', x)
Thanks to Allen for the swift turnaround of these changes.
And to close the loop: rev37 makes clear that ResolveExport() will follow re-exported import bindings to discover the module in which they originated. This makes all the assertions correct. In my example, it means that the CreateImportBinding call in 'a' is: CreateImportBinding(x, 'c', x) Thanks to Allen for the swift turnaround of these changes. On Thu, Apr 2, 2015 at 8:17 AM, Adam Klein <adamk at chromium.org> wrote: > I've added this to a few bugs on the bug-tracker: > > https://bugs.ecmascript.org/show_bug.cgi?id=4184 (CreateImportBinding) > https://bugs.ecmascript.org/show_bug.cgi?id=4244 (GetExportedNames and > ResolveExport) > > On Wed, Apr 1, 2015 at 4:31 PM, Adam Klein <adamk at chromium.org> wrote: > >> I have a question about CreateImportBinding(N, M, N2) (where N is the >> name to create in the importing module, and M is a module which exports N2). >> >> Step 4 of >> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-createimportbinding >> is the following assertion >> >> "Assert: When M.[[Environment]] is instantiated it will have a direct >> binding for N2." >> >> What about the case were M is simply re-exporting an import? Consider: >> >> --------- >> module 'a': >> >> import { x } from 'b'; >> >> --------- >> module 'b': >> >> import { x } from 'c'; >> export { x }; >> >> --------- >> module 'c': >> >> export let x = 42; >> >> --------- >> >> In this case, when running CreateImportBinding(x, 'b', x) in module 'a', >> the assertion fails, as x in 'b' is an "immutable indirect binding" (itself >> created by CreateImportBinding). >> >> Is there a need for this assert I'm missing? I don't think skipping over >> this assert, or removing "direct" from its wording, will cause any >> problems. Also, the term "direct binding" is not defined anywhere that I >> can find, except as the negation of the "indirect" binding created by >> CreateImportBinding. >> >> Note that there's a similar issue in ResolveExport: step 4.a.i of >> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-resolveexport >> asserts that resolved exports found in [[LocalExportEntries]] are "leaf >> bindings" (another term that goes undefined), where by the usual CS >> definition of "leaf" the assertion would be false for x in 'b' (when >> resolved from 'a'). >> >> - Adam >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150406/a97f0262/attachment.html>
I have a question about CreateImportBinding(N, M, N2) (where N is the name to create in the importing module, and M is a module which exports N2).
Step 4 of people.mozilla.org/~jorendorff/es6-draft.html#sec-createimportbinding is the following assertion
"Assert: When M.[[Environment]] is instantiated it will have a direct binding for N2."
What about the case were M is simply re-exporting an import? Consider:
module 'a': import { x } from 'b';
module 'b': import { x } from 'c'; export { x };
module 'c': export let x = 42;
In this case, when running CreateImportBinding(x, 'b', x) in module 'a', the assertion fails, as x in 'b' is an "immutable indirect binding" (itself created by CreateImportBinding).
Is there a need for this assert I'm missing? I don't think skipping over this assert, or removing "direct" from its wording, will cause any problems. Also, the term "direct binding" is not defined anywhere that I can find, except as the negation of the "indirect" binding created by CreateImportBinding.
Note that there's a similar issue in ResolveExport: step 4.a.i of people.mozilla.org/~jorendorff/es6-draft.html#sec-resolveexport asserts that resolved exports found in [[LocalExportEntries]] are "leaf bindings" (another term that goes undefined), where by the usual CS definition of "leaf" the assertion would be false for x in 'b' (when resolved from 'a').