TC39 Module Harmony
2022-08-02
plaintext logs
prev next
source on github
12:02
<Jack Works>
šŸ˜†
16:00
<Kris Kowal>
Iā€™ll be on the call shortly
16:02
<Luca Casonato>
is anyone in the call that could let me in?
17:42
<yulia>
sorry for coming across so strong. My opinion is not so intense. It was largely due to the time constraint
17:42
<littledan>
it's fine, I was also probably talking too much that meeting and apologize for that
17:43
<Kris Kowal>
Weā€™re in agreement that the syntax should be thoroughly discussed.
17:55
<Kris Kowal>
sent an image.
Whatā€™s this? Looks like the future.
18:03
<mkubilayk>
I do sympathize with yulia's point of import module potentially being confusing to a regular developer, who would naturally think that they have always been importing "modules" but now there is this thing called import module that does something different.
18:05
<mkubilayk>
Separately, I really like the idea of building a topology of the ongoing proposals and similarly a capability graph. I think they would be massively helpful to anyone like me who's getting into this space.
18:08
<Kris Kowal>
Module is one of those words. Mark Miller insists that nothing should be called module because so many things could be called modules when you strip off the qualifiers.
18:08
<Kris Kowal>
I mean one of ā€œthose wordsā€ which is the category including words like test.
18:10
<Kris Kowal>
Of course, thereā€™s no more sensible word than module for module blocks, and it should be intuitively obvious that module blocks are instances of Module once word gets out.
18:11
<Kris Kowal>
One thing sort of leads to another from there.
18:12
<littledan>
hmm, I feel like I'm the source of asking that we go back and use module for everything...
18:12
<littledan>
and it seems like a bad idea exactly for the reason Mark says
18:13
<littledan>
One thing sort of leads to another from there.
I agree that this is how we arrived where we are but it seems bad
18:14
<Kris Kowal>
I also could buy import x from 'y' as module, but that doesnā€™t address the ā€œwhatā€™s a module? i thought module was a synecdoche of module exports namespace exotic objects.ā€
18:15
<littledan>
I also could buy import x from 'y' as module, but that doesnā€™t address the ā€œwhatā€™s a module? i thought module was a synecdoche of module exports namespace exotic objects.ā€
Yes, and it means that as identifier means two different things in import statements (even worse than when it was as "string")
18:15
<littledan>
but generally yes I can buy putting the modifier on the right
18:15
<Kris Kowal>
Yeah, I agree thatā€™s not ideal.
18:16
<Kris Kowal>
Right.
18:16
<littledan>
and I can buy "object literals are just too syntactically heavy for this"
18:16
<Kris Kowal>
Iā€™m still leaning on left, but also donā€™t like that it would overlap with lexically named module fragments maybe someday.
18:17
<littledan>
well, I don't think that module needs to be the only keyword that introduces something into the lexically named module fragments namespace
18:17
<Kris Kowal>
Itā€™s an interesting puzzle once all the pieces are out :-)
18:19
<Kris Kowal>
If we go back to qualifying ā€œmoduleā€, I donā€™t like ā€œinstanceā€ because it leads to language like ā€œModuleInstance instanceā€.
18:22
<yulia>
I'm potentially amenable to import source x from y
18:22
<littledan>
I think that'd make sense for module blocks/fragments too, to use source as the keyword
18:22
<yulia>
import assertions / the right hand side, not being used is maybe a shame. but as mentioned if we have a clear relationship as daniel outlined that may be fine
18:23
<yulia>
my comments in the call were more that daniel and i had discussed the issue, but i wanted to hear what you folks thought of my complaints
18:23
<littledan>
oh! sorry for talking so much
18:24
<littledan>
I'm potentially amenable to import source x from y
but... it's funny since we were thinking of the "source" brand for, you know, the ModuleSource, as opposed to the ModuleInstance
18:24
<yulia>
yep, this would fit more with guy's thinking
18:24
<yulia>
i don't know what to call the thing in between
18:25
<yulia>
instance is... a bit weird
18:25
<littledan>
well, yeah, this still doesn't resolve the question about whether we want two new kinds of import statements or one
18:26
<littledan>
or if we feel that import module is not an important thing to be able to express, otoh
18:26
<Kris Kowal>
Module Node would be valid.
18:27
<Kris Kowal>
And weā€™ve already denied corporate aggressors ownership of ā€œmetaā€. No reason not to do the same to those who would appropriate common words like ā€œnodeā€ or ā€œgoā€.
18:27
Kris Kowal
checks caffeine. Uh oh.
18:28
<littledan>
import agoric x from "./y"
18:29
<Kris Kowal>
import agoric x from "./y"
As long as thatā€™s coming from you! From me, one might construe that it increases shareholder value too much.
18:29
<littledan>
or maybe destroys your trademark
18:30
<Kris Kowal>
RIP
18:30
<guybedford>
this could be a JS sponsorship opportunity....
18:30
<guybedford>
reflect as a keyword might be interesting
18:30
<guybedford>
source is good
18:30
<Kris Kowal>
ā€œAnd thatā€™s how import oracle happened.ā€
18:31
<guybedford>
lol, that'll show them
18:31
<Kris Kowal>
reflect as a keyword might be interesting
I donā€™t hate it.
18:31
<Kris Kowal>
lol, that'll show them
Owning the trademark was clearly not enough.
18:31
<littledan>
I feel like reflect is a bit ambiguous; there's lots of layers of reflection in JS
18:31
<Kris Kowal>
Thatā€™s true.
18:31
<littledan>
ideally we'd find a word which somehow means like "uninstantiated"
18:32
<Kris Kowal>
Module ā€œnodesā€ and sources are both reflections.
18:32
<Kris Kowal>
ideally we'd find a word which somehow means like "uninstantiated"
The state is not guaranteed to be any particular value.
18:33
<guybedford>
I'd just hope we can avoid picking up the syntax discussion as explicitly name bikeshedding too much for now
18:34
<guybedford>
I mean for the next meeting
18:34
<Kris Kowal>
import s from 'x.js' as source; // module source
import n from 'x.js' as node; // module node
import * as e from 'x.js'; // module namespace guarantees n is in evaluated state
18:35
<guybedford>
if we're making syntax the initial starting point
18:35
<guybedford>
I can get behind most of the suggestions above though!
18:36
<littledan>
sorry what does "node" mean?
18:36
<Kris Kowal>
Riffing on ā€œnode of module graphā€ what weā€™re currently calling a Module instance.
18:37
<yulia>
what about import lazy for uninstantiated?
18:37
<littledan>
I'd just hope we can avoid picking up the syntax discussion as explicitly name bikeshedding too much for now
Well, on the contrary, I think when we came to the point of understanding that we might just change the keyword "module" for something else, and that might be a solution, that was some real progress. Let's timebox any bikeshedding though.
18:38
<littledan>
what about import lazy for uninstantiated?
I like this, though it really doesn't map to module blocks
18:38
<yulia>
hmm module blocks are linked right?
18:39
<Kris Kowal>
Remind me what the effect of lazy is?
18:39
<littledan>
no, they can be imported but they are "lazy" in the same way
18:39
<yulia>
Lazy: its a linked module source that hasn't been evaluated yet
18:39
<littledan>
what do you mean by linked?
18:39
<Kris Kowal>
(Because I suspect we get lazy for free from importing nodes of the module graph and module blocks)
18:39
<yulia>
as in, the module graph is traversed
18:39
<yulia>
and all of its peers are loaded
18:39
<yulia>
but not executed
18:39
<Kris Kowal>
Ah.
18:40
<littledan>
well, I think for the Wasm use case for import reflection, we really can't eagerly traverse the module graph
18:40
<yulia>
right, but we would have source for that
18:40
<littledan>
because the specifiers may mean something totally different
18:40
<Kris Kowal>
Aye. Thatā€™s also necessary for bundling.
18:40
<littledan>
hmm, well, this is a meaningful place where we have multiple policies, and something we should discuss IMO
18:40
<yulia>
yes, of course
18:40
<Kris Kowal>
Module blocks and module ā€œnode in graphā€ imports should be inherently lazy, imo.
18:41
<littledan>
I think there are use cases for both policies
18:41
<Kris Kowal>
I agree.
18:41
<littledan>
and... you could have attributes that let you select
18:41
<Kris Kowal>
Iā€™m not sure whether the policy belongs in syntax. I have to think about it.
18:41
<littledan>
I don't know either
18:41
<Kris Kowal>
But bundling motivates both lazy and eager, depending on the context.
18:41
<yulia>
ok so for the schema, right now we have import [stage] x from y [modifiers
18:42
<yulia>
thats pretty intersting
18:42
<yulia>
it gets a bit messy when we also have import type <etc> though
18:42
<littledan>
I'm not really sure if stage and laziness are the same thing
18:42
<yulia>
maybe layer is a better term?
18:42
<yulia>
what i mean is we don't apply all steps of module loading
18:43
<Kris Kowal>
On the producer side of a bundle, all static imports must be eager. On the consumer side, module blocks in a bundle must be lazy.
18:44
<Kris Kowal>
Though, there are likely exceptions to the rule.
18:44
<Kris Kowal>
And it would be not so good to force bundlers to resort to comments. That would be antithetical to providing a system that doesnā€™t require a usercode JS parser.
18:45
<yulia>
why would they need comments? sorry if i am not catching the obvious
18:45
<littledan>
to indicate stage/layer if we don't make a syntax for it?
18:46
<Kris Kowal>
Itā€™s fine. Consider the case of bundling a module block for purposes of transmission to a worker.
18:46
<yulia>
ah, because module vs lazy
18:46
<yulia>
would it be lazy in the context of a worker?
18:47
<yulia>
i would have guessed that it is executed on arrival but i may not have kept up / got it wrong
18:47
<Kris Kowal>
Youā€™re not wrong.
18:47
<littledan>
we're talking about laziness of fetching imports, right?
18:48
<yulia>
yes, roughly aligned with what i was thinking for deferred evaluation, minus the behind-the-scenes replacement
18:48
<yulia>
which is still an important dx thing.. but i am open to the discussion
18:49
<littledan>

like, there are four possible levels of laziness:

  • Laziest: Don't even fetch at the top level (asset reference)
  • Lazier: Fetch at the top level, don't fetch dependencies (what I thought import module was)
  • Unexecuted: Fetch dependencies but don't execute (what's being raised for bundlers needing)
  • Just a normal import: Fetch dependencies and execute
18:49
<yulia>
lazier aligns with what i thought import module was (though i quite like import source?)
18:50
<Kris Kowal>
I propose a useful constraint on our design: it should be possible to author an entire application that includes workers and transmits module blocks to workers in such a way that the sources do not need to be altered between development and production.
18:51
<Kris Kowal>
Or, paraphrase, the sources must not be changed in order for tooling to produce production object code.
18:51
<littledan>
I think a general design goal should be, it should be possible for build pipelines to shrink over time if optimizations aren't happening. This is an incremental process, not really something we can consider an absolute constraint.
18:51
<littledan>
like, we're not proposing JSX
18:51
<Kris Kowal>
Right.
18:51
<yulia>
Lol my computer died mid sentence
18:51
<yulia>
Iā€™ll head off for the night
18:51
<yulia>
I think itā€™s a sign
18:52
<Kris Kowal>
But the point is that the build pipeline will see module blocks that require various treatments for purposes of generating bundles for each worker.
18:52
<littledan>
good night! I'm looking forward to continuing this discussion
18:52
<yulia>
Likewise
18:52
<Kris Kowal>
Sleep well, yulia and yuliaā€™s computer.