Re-exporting imports and CreateImportBinding assertions
# Adam Klein (11 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 (11 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').
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/20150401/5b4eda78/attachment.html>