-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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 Source Phase Imports #3094
base: main
Are you sure you want to change the base?
Conversation
</table> | ||
</emu-table> | ||
|
||
<emu-note type="editor">In general, this proposal replaces places where module specifiers are passed around with ModuleRequest Records. For example, several syntax-directed operations, such as ModuleRequests produce Lists of ModuleRequest Records rather than Lists of Strings which are interpreted as module specifiers. Some algorithms like ImportEntries and ImportEntriesForModule pass around ModuleRequest Records rather than Strings, in a way which doesn't require any particular textual change. Additionally, record fields in Cyclic Module Records and Source Text Module Records which contained Lists of Strings are replaced by Lists of ModuleRequest Records, as indicated above.</emu-note> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The exact layout of this record depend on #3057. There is cleanup to be done around how and where exactly phases are passed around (and if they are part of this record), but this will be less merge conflict prone once Nicolo's PR is merged.
The PR is technically correct as is, so I'll defer this work until Import Attributes is landed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'll also have to add [[Phase]]
to LoadedModuleRequest Records.
07332fb
to
52fed39
Compare
<li>along with its corresponding prototype object, provides common properties that are inherited by module source constructors and their instances.</li> | ||
<li>does not have a global name or appear as a property of the global object.</li> | ||
<li>acts as the abstract superclass of the _ModuleSource_ constructor.</li> | ||
<li>will throw an error when invoked, because it is an abstract class constructor. The module source constructors do not perform a `super` call to it.</li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm not sure we have the concept of an "abstract" class constructor; can't it be a normal constructor that throws both when [[Call]]ed or when it's its own new.target
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ljharb Do you mean you want it to be possible to do like
let AbstractModuleSource = /* some coe which gets AbstractModuleSource somehow */;
class A extends AbstractModuleSource {}
new A()
and have that not throw?
If so, that can't be done while keeping the property mentioned above, that these things are supposed to all have a [[ModuleSourceRecord]] internal slot holding a ModuleSource Record - there's no way to provide one when constructing from user code.
Or do you just mean you don't like the wording "abstract class constructor" here, and are OK with the behavior but want different wording?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The semantics are fine, i indeed just mean the word "abstract" doesn't appear in the spec in this context afaik, and I don't think we should introduce it short of a proposal to add some kind of language feature for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can't it be a normal constructor that throws both when [[Call]]ed or when it's its own
new.target
?
Yes, we should do this, and we should get rid of
The module source constructors do not perform a
super
call to it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the resolution of this? The current version I'm reading has an %AbstractModuleSource% constructor that unconditionally throws for both [[Call]] and [[Construct]].
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intention here is the following:
- User code can not [[Call]] and [[Construct]] the %AbstractModuleSource% constructor.
- Host objects can inherit from %AbstractModuleSource%.
- Host objects (like
WebAssembly.Module
) that inherit from %AbstractModuleSource% should be able to be constructed by user code (if the relevant host object constructor allows this).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
User code should be able to class extends AbstractModuleSource
, though, otherwise you can't self-host a JS implementation and get the right internal slot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since only hosts are able to implement custom module sources, and not user code, this is explicitly designed to ensure class extends AbstractModuleSource
doesn't work.
spec.html
Outdated
GetModuleSource() | ||
</td> | ||
<td> | ||
<p>It returns either a normal completion completion for the ModuleSource Object corresponding to this source Module Record's source phase (<emu-xref href="#sec-module-source-objects"></emu-xref>), or a throw completion.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Below this is spelled "Module Source Object", rather than "ModuleSource Object". It should be consistent (and ideally <dfn>
'd).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a space in tc39/proposal-source-phase-imports#52. I don't want to call this a definition since these are a class of objects as opposed to a specific object here.
<li>along with its corresponding prototype object, provides common properties that are inherited by module source constructors and their instances.</li> | ||
<li>does not have a global name or appear as a property of the global object.</li> | ||
<li>acts as the abstract superclass of the _ModuleSource_ constructor.</li> | ||
<li>will throw an error when invoked, because it is an abstract class constructor. The module source constructors do not perform a `super` call to it.</li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ljharb Do you mean you want it to be possible to do like
let AbstractModuleSource = /* some coe which gets AbstractModuleSource somehow */;
class A extends AbstractModuleSource {}
new A()
and have that not throw?
If so, that can't be done while keeping the property mentioned above, that these things are supposed to all have a [[ModuleSourceRecord]] internal slot holding a ModuleSource Record - there's no way to provide one when constructing from user code.
Or do you just mean you don't like the wording "abstract class constructor" here, and are OK with the behavior but want different wording?
Rather than making a bunch of suggestions here, I've created a PR against this PR's branch: lucacasonato#1 |
<emu-clause id="sec-static-semantics-modulerequests" oldids="sec-module-semantics-static-semantics-modulerequests,sec-imports-static-semantics-modulerequests,sec-exports-static-semantics-modulerequests" type="sdo"> | ||
<h1>Static Semantics: ModuleRequests ( ): a List of Strings</h1> | ||
<h1>Static Semantics: ModuleRequests ( ): a List of ModuleRequest Records</h1> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In ExportEntries()
, there's an invocation of ModuleRequests
that needs to accommodate this change in the return-type.
spec.html
Outdated
GetModuleSource() | ||
</td> | ||
<td> | ||
<p>It returns either a normal completion completion for the ModuleSource Object corresponding to this source Module Record's source phase (<emu-xref href="#sec-module-source-objects"></emu-xref>), or a throw completion.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<p>It returns either a normal completion completion for the ModuleSource Object corresponding to this source Module Record's source phase (<emu-xref href="#sec-module-source-objects"></emu-xref>), or a throw completion.</p> | |
<p>It returns either a normal completion containing the Module Source Object corresponding to this Module Record, or a throw completion.</p> |
Assuming we <dfn>
"Module Source Object" below.
<h1>Module Source Objects</h1> | ||
<p>Module Source Objects represent modules in their source import phase, which are not linked, instantiated or executed.</p> | ||
<p>All Module Source Objects should have a prototype of %AbstractModuleSource%.prototype and must define a [[ModuleSourceRecord]] internal slot.</p> | ||
<p>Hosts may define their own Module Source subclasses for custom module record types.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does "record" mean here?
<p>Hosts may define their own Module Source subclasses for custom module record types.</p> | |
<p>Hosts may define their own Module Source subclasses for custom module types.</p> |
Also, wouldn't they be %AbstractModuleSource%
subclasses?
<p>Hosts may define their own Module Source subclasses for custom module record types.</p> | |
<p>Hosts may define their own %AbstractModuleSource% subclasses for custom module types.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we're trying to say "Hosts may define their own %AbstractModuleSource% subclasses for custom Module Record subtypes/subclasses/subrecords."
Not sure about that last word.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm % some questions.
P.S. Be sure to run npm run format
.
spec.html
Outdated
@@ -18754,6 +18754,7 @@ <h2>Syntax</h2> | |||
|
|||
ImportCall[Yield, Await] : | |||
`import` `(` AssignmentExpression[+In, ?Yield, ?Await] `)` | |||
`import` `.` `source` `(` AssignmentExpression[+In, ?Yield, ?Await] `)` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Speaking as a delegate, not editor, I've gotten feedback that there is a somewhat strong intuition that source
refers to unparsed code. Are champions still open to bikeshedding the phase name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the unparsed source will be import.asset
in the future. I don't know if there is a better name for this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup. Wasm uses module
, but within the module harmony group we are of the opinion that module
refers to a module instance (source + context).
This is reflected in the designs for Module expressions, Module declarations, and Module loaders.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Internally in V8 we bikshedded handle
and instantiable
.
<li>along with its corresponding prototype object, provides common properties that are inherited by module source constructors and their instances.</li> | ||
<li>does not have a global name or appear as a property of the global object.</li> | ||
<li>acts as the abstract superclass of the _ModuleSource_ constructor.</li> | ||
<li>will throw an error when invoked, because it is an abstract class constructor. The module source constructors do not perform a `super` call to it.</li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the resolution of this? The current version I'm reading has an %AbstractModuleSource% constructor that unconditionally throws for both [[Call]] and [[Construct]].
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reminder that I created lucacasonato#1 a month ago.
[[Specifier]] | ||
</td> | ||
<td> | ||
String |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
String | |
a String |
This is now superseded by #3492. |
https://github.com/tc39/proposal-source-phase-imports