Skip to content

Draft spec text #10

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.

Sign up for GitHub

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

Merged
merged 5 commits into from
Jul 30, 2025
Merged

Draft spec text #10

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
30fe82e
draft spec text
guybedford Jul 28, 2025
1f3caa6
fix closing tag
guybedford Jul 28, 2025
856b86e
fixup build
guybedford Jul 28, 2025
e2ca117
add authors / contributors
guybedford Jul 28, 2025
62d0aa2
typo
guybedford Jul 28, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,8 @@

Champions: [@styfle](https://github.com/styfle)

Author(s): [@styfle](https://github.com/styfle), Guy Bedford

Status: Stage 0.

Please leave any feedback in the [issues](https://github.com/styfle/proposal-import-bytes/issues), thanks!
Expand Down
2 changes: 1 addition & 1 deletion package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
"private": true,
"scripts": {
"start": "npm run build-loose -- --watch",
"build": "npm run build-loose -- --strict",
"build": "npm run build-loose",
"build-loose": "node -e 'fs.mkdirSync(\"build\", { recursive: true })' && ecmarkup --load-biblio @tc39/ecma262-biblio --verbose spec.emu build/index.html --lint-spec"
},
"license": "MIT",
Expand Down
201 changes: 21 additions & 180 deletions spec.emu
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,13 +6,13 @@
<pre class="metadata">
title: Proposal Import Bytes
stage: 0
contributors: Steven
contributors: Steven, Guy Bedford
</pre>
<emu-intro id="intro">
<h1>Proposal Import Bytes</h1>
<p>See <a href="https://github.com/styfle/proposal-import-bytes/blob/main/README.md">the explainer</a> for information.</p>
<emu-note type="editor">
<p>This proposal is buit on top of the <a href="https://github.com/tc39/proposal-import-attributes">Import Attributes</a> proposal.</p>
<p>This proposal is buit on top of the <a href="https://github.com/tc39/proposal-json-modules">JSON Modules</a> and <a href="https://github.com/tc39/proposal-immutable-arraybuffer">Immutable Array Buffer</a> proposals.</p>
Copy link
Member

Choose a reason for hiding this comment

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

Might need to update the readme as well if we want to swap import-attributes for json-modules

Copy link
Member

Choose a reason for hiding this comment

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

Actually, I think import-attributes is correct.

This proposal is built on top of import-attributes, not json-modules.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The way I framed it we are sharing JSON modules text per the next comment.

</emu-note>
</emu-intro>

Expand Down Expand Up @@ -56,9 +56,13 @@ contributors: Steven
</ul>
<p>then it must perform FinishLoadingImportedModule(_referrer_, _moduleRequest_, _payload_, _result_) with the same _result_ each time.</p>
</li>
<li>
<p><ins>If _moduleRequest_.[[Attributes]] has an entry _entry_ such that _entry_.[[Key]] is *"type"* and _entry_.[[Value]] is *"json"*, the host environment must perform FinishLoadingImportedModule(_referrer_, _moduleRequest_, _payload_, _result_), where _result_ is either the Completion Record returned by an invokation of ParseJSONModule or a throw completion.</ins></p>
</li>
<li><p><del>If _moduleRequest_.[[Attributes]] has an entry _entry_ such that _entry_.[[Key]] is *"type"* and _entry_.[[Value]] is *"json"*, the host environment must perform FinishLoadingImportedModule(_referrer_, _moduleRequest_, _payload_, _result_), where _result_ is either the Completion Record returned by an invokation of ParseJSONModule or a throw completion.</del></p></li>
<li><p><ins>If _moduleRequest_.[[Attributes]] has an entry _entry_ such that _entry_.[[Key]] is *"type"*, then</ins></p></li>
<ol>
<li><p><ins>Let _type_ be _entry_.[[Value]].</ins></p></li>
<li><p><ins>If _type_ is *"json"*, the host environment must perform FinishLoadingImportedModule(_referrer_, _moduleRequest_, _payload_, _result_), where _result_ is either the Completion Record returned by an invokation of ParseJSONModule or a throw completion.</ins></p></li>
<li><p><ins>If _type_ is *"buffer"*, the host environment must perform FinishLoadingImportedModule(_referrer_, _moduleRequest_, _payload_, _result_), where _result_ is either the Completion Record returned by an invokation of CreateBufferModule or a throw completion.</ins></p></li>
</ol>
<li>
The operation must treat _payload_ as an opaque value to be passed through to FinishLoadingImportedModule.
</li>
Expand All @@ -67,11 +71,11 @@ contributors: Steven
<p>The actual process performed is host-defined, but typically consists of performing whatever I/O operations are necessary to load the appropriate Module Record. Multiple different (_referrer_, _moduleRequest_.[[Specifer]], _moduleRequest_.[[Attributes]]) triples may map to the same Module Record instance. The actual mapping semantics is host-defined but typically a normalization process is applied to _specifier_ as part of the mapping process. A typical normalization process would include actions such as expansion of relative and abbreviated path specifiers.</p>

<emu-note>
<p><ins>The above text implies that hosts *must* support JSON modules imported with `type: "json"` (if it completes normally), but it doesn't prohibit hosts from supporting JSON modules imported with no type specified. Some environments (for example, web browsers) plan to require `with { type: "json" }`, and environments which want to restrict themselves to a compatible subset would do so as well.</ins></p>
<p>The above text implies that hosts *must* support JSON modules <ins>and buffer modules</ins> imported with `type: "json"` <ins>and `type: "buffer"` respectively </ins>(if it completes normally), but it doesn't prohibit hosts from supporting JSON modules imported with no type specified. Some environments (for example, web browsers) plan to require `with { type: "json" }`, and environments which want to restrict themselves to a compatible subset would do so as well.</p>
Copy link
Member

Choose a reason for hiding this comment

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

I think we need to remove the type: "json" part mentioned here, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because I've based this to JSON modules, it's sharing this note with JSON modules.

</emu-note>

<emu-note>
<p><ins>All of the import statements in the module graph that address the same JSON module may evaluate to the same mutable object.</ins></p>
<p>All of the import statements in the module graph that address the same JSON <ins>or buffer </ins>module may evaluate to the same mutable object.</p>
</emu-note>
</emu-clause>

Expand All @@ -80,7 +84,7 @@ contributors: Steven

<p>A <dfn variants="Synthetic Module Records">Synthetic Module Record</dfn> is used to represent information about a module that is defined by specifications. Its exports are derived from a pair of lists, of string keys and of ECMAScript values. The set of exported names is static, and determined at creation time (as an argument to CreateSyntheticModule), while the set of exported values can be changed over time using SetSyntheticModuleExport. It has no imports or dependencies.</p>

<emu-note>A Synthetic Module Record could be used for defining a variety of module types: for example, built-in modules, or JSON modules, or CSS modules.</emu-note>
<emu-note>A Synthetic Module Record could be used for defining a variety of module types: for example, built-in modules, or JSON modules, <ins>or buffer modules, </ins>or CSS modules.</emu-note>

<p>In addition to the fields defined in <emu-xref href="#table-module-record-fields"></emu-xref> Synthetic Module Records have the additional fields listed in <emu-xref href="#table-synthetic-module-record-fields"></emu-xref>. Each of these fields is initially set in CreateSyntheticModule.</p>

Expand All @@ -106,186 +110,23 @@ contributors: Steven
</table>
</emu-table>

<emu-clause id="sec-createsyntheticmodule" type="abstract operation">
<h1>
CreateSyntheticModule (
_exportNames_: a List of Strings without duplicates,
_evaluationSteps_: an Abstract Closure,
_realm_: a Realm Record,
): a Synthetic Module Record
</h1>
<dl class="header">
<dt>description</dt>
<dd>It creates a Synthetic Module Record based upon the given exported names and evaluation steps.</dd>
</dl>

<emu-alg>
1. Return Synthetic Module Record { [[Realm]]: _realm_, [[Environment]]: ~empty~, [[Namespace]]: ~empty~, [[HostDefined]]: ~empty~, [[ExportNames]]: _exportNames_, [[EvaluationSteps]]: _evaluationSteps_ }.
</emu-alg>

<emu-note type="editor">It seems we could set up the environment either here or in Link(). I've chosen to do so in Link() for symmetry with Cyclic Module Records (and thus Source Text Module Records), but I don't think there's any actual requirement in that regard.</emu-note>
</emu-clause>

<emu-clause id="sec-setsyntheticmoduleexport" type="abstract operation">
<emu-clause id="sec-create-buffer-module" type="abstract operation">
<h1>
SetSyntheticModuleExport (
_module_: a Synthetic Module Record,
_exportName_: a String,
_exportValue_: an ECMAScript Language value
): ~unused~
</h1>
<dl class="header">
<dt>description</dt>
<dd>It can be used to set or change the exported value for a pre-established export of a Synthetic Module Record.</dd>
</dl>

<emu-alg>
1. Let _envRec_ be _module_.[[Environment]].
1. Assert: _envRec_ is not ~empty~.
1. Perform _envRec_.SetMutableBinding(_exportName_, _exportValue_, *true*).
1. Return ~unused~.
</emu-alg>
</emu-clause>

<emu-clause id="sec-smr-concrete-methods">
<h1>Concrete Methods</h1>

<p>The following are the concrete methods for Synthetic Module Record that implement the corresponding Module Record abstract methods.</p>

<emu-note type="editor">I find having this wrapping sub-clause cleaner and suggest we do the same for Source Text Module Records in the main spec.</emu-note>

<emu-clause id="sec-smr-LoadRequestedModules" type="concrete method">
<h1>
LoadRequestedModules (): a Promise
</h1>
<dl class="header">
<dt>for</dt>
<dd>a Synthetic Module Record _module_</dd>
</dl>

<emu-alg>
1. Return ! PromiseResolve(%Promise%, *undefined*).
</emu-alg>

<emu-note>
Synthetic Module Records have no dependencies.
</emu-note>
</emu-clause>

<emu-clause id="sec-smr-getexportednames" type="concrete method">
<h1>
GetExportedNames (): a List of Strings
</h1>
<dl class="header">
<dt>for</dt>
<dd>a Synthetic Module Record _module_</dd>
</dl>

<emu-alg>
1. Return _module_.[[ExportNames]].
</emu-alg>
</emu-clause>

<emu-clause id="sec-smr-resolveexport" type="concrete method">
<h1>
ResolveExport(
_exportName_: a String,
): a ResolvedBinding Record or *null*
</h1>
<dl class="header">
<dt>for</dt>
<dd>a Synthetic Module Record _module_</dd>
</dl>

<emu-alg>
1. If _module_.[[ExportNames]] does not contain _exportName_, return *null*.
1. Return ResolvedBinding Record { [[Module]]: _module_, [[BindingName]]: _exportName_ }.
</emu-alg>
</emu-clause>

<emu-clause id="sec-smr-Link" type="concrete method">
<h1>Link ( ): ~unused~</h1>
<dl class="header">
<dt>for</dt>
<dd>a Synthetic Module Record _module_</dd>
</dl>

<emu-alg>
1. Let _realm_ be _module_.[[Realm]].
1. Let _env_ be NewModuleEnvironment(_realm_.[[GlobalEnv]]).
1. Set _module_.[[Environment]] to _env_.
1. For each String _exportName_ in _module_.[[ExportNames]], do
1. Perform ! _env_.CreateMutableBinding(_exportName_, *false*).
1. Perform ! _env_.InitializeBinding(_exportName_, *undefined*).
1. Return ~unused~.
</emu-alg>
</emu-clause>

<emu-clause id="sec-smr-Evaluate" type="concrete method">
<h1>Evaluate ( ): a Promise</h1>
<dl class="header">
<dt>for</dt>
<dd>a Synthetic Module Record _module_</dd>
</dl>

<emu-alg>
1. Let _moduleContext_ be a new ECMAScript code execution context.
1. Set the Function of _moduleContext_ to *null*.
1. Set the Realm of _moduleContext_ to _module_.[[Realm]].
1. Set the ScriptOrModule of _moduleContext_ to _module_.
1. Set the VariableEnvironment of _moduleContext_ to _module_.[[Environment]].
1. Set the LexicalEnvironment of _moduleContext_ to _module_.[[Environment]].
1. Suspend the currently running execution context.
1. Push _moduleContext_ on to the execution context stack; _moduleContext_ is now the running execution context.
1. Let _steps_ be _module_.[[EvaluationSteps]].
1. Let _result_ be Completion(_steps_(_module_)).
1. Suspend _moduleContext_ and remove it from the execution context stack.
1. Resume the context that is now on the top of the execution context stack as the running execution context.
1. Let _pc_ be ! NewPromiseCapability(%Promise%).
1. IfAbruptRejectPromise(_result_, _pc_).
1. Perform ! _pc_.[[Resolve]](_result_).
1. Return _pc_.[[Promise]].
</emu-alg>
</emu-clause>
</emu-clause>

<emu-clause id="sec-create-default-export-synthetic-module" type="abstract operation">
<h1>
CreateDefaultExportSyntheticModule (
_defaultExport_: an ECMAScript Language value,
): a Synthetic Module Record
</h1>
<dl class="header">
<dt>description</dt>
<dd>It creates a Synthetic Module Record whose default export is _defaultExport_.</dd>
</dl>
<emu-alg>
1. Let _realm_ be the current Realm Record.
1. Let _setDefaultExport_ be a new Abstract Closure with parameters (_module_) that captures _defaultExport_ and performs the following steps when called:
1. Perform SetSyntheticModuleExport(_module_, *"default"*, _defaultExport_).
1. Return CreateSyntheticModule(« *"default"* », _setDefaultExport_, _realm_).
</emu-alg>
</emu-clause>

<emu-clause id="sec-parse-json-module" type="abstract operation">
<h1>
ParseJSONModule (
_source_: a String
): either a normal completion containing a Synthetic Module Record, or a throw completion
<ins>
CreateBufferModule (
_arrayBuffer_: an immutable ArrayBuffer or a SharedArrayBuffer
): a Synthetic Module Record
</ins>
</h1>
<dl class="header">
<dt>description</dt>
<dd></dd>
</dl>

<emu-alg>
1. Let _json_ be ? Call(%JSON.parse%, *undefined*, « _source_ »).
1. Return CreateDefaultExportSyntheticModule(_json_).
1. Assert: IsImmutableBuffer(_arrayBuffer_) is *true*.
1. Return CreateDefaultExportSyntheticModule(_arrayBuffer_).
</emu-alg>

<emu-note type="editor">
TODO: Refactor JSONParse into an abstract algorithm.
</emu-note>
</emu-clause>
</emu-clause>
</emu-clause>
</emu-clause>