►
From YouTube: SES-mtg: 21 October 2020
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
and
oh,
that's
right!
This
is
how
I'm
sharing
screen
today.
A
And
transition
is
this
working
cool,
trying
a
new
thing.
B
A
All
right
so
to
recap:
the
compartments
proposal.
Compartments
are
a
mechanism
for
running
client
code
in
a
javascript
environment
with
limited
powers,
isolated,
evaluators,
unique
globals,
but
shared
prototypes
and
lockdown
is
a
mechanism
for
freezing
shared
prototypes.
So
compartments
and
lockdown
are
two
great
flavors
that
are
better
together.
B
A
A
No
in
any
case
going
in.
So
one
of
the
things
that
I'm
proposing
for
the
proposal
for
compartments
as
it's
written
today
is
that
we
add
a
name.
The
purpose
of
adding
a
name
to
a
compartment
is
that
well
for
one
it.
It
strongly
parallels
what
exists
today
already
for
the
function
constructor,
and
it
gives
us
a
mechanism
for
communicating
to
the
user
in
stack
traces
about
the
compartment
that
originates
an
error.
A
Well,
partner
function,
instances
have
a
name
right,
as
compartment
instances
would
have
a
name
and
the,
and
the
purpose
of
this
is
that
it
would
allow
us
to
annotate
exceptions
that
escape
evaluators
in
the
compartment,
so
that
people
could
figure
out
where
they
originated
and
I'm
proposing
adding
support
for
loading
without
executing,
which
we've
added
to
the
shim,
and
that
has
allowed
us
to
do
enough
to
do
archiving
in
particular.
A
But
there
are
a
number
of
useful
use
cases
for
being
able
to
load
without
executing
it
can
we
can
use
a
compartment
to
drive
the
loading
of
the
transitive
modules
of
a
particular
entry
point
for
static
analysis
and
to
capture
to
capture
an
entire
application
for
different,
repeated
execution,
which
is
to
say
that
you
could
use
this
to
drive
the
the
load
hooks
to
to
get
all
of
the
static
module
records
and
thereby
record
record
all
of
those
static
record.
All
of
those
static
mic?
A
Have
it
cache
the
the
static
module
records
so
that
they
can
be
created
in
other
compartments
and
and
of
course,
our
particular
use
case
that
agora
could
be
recording
an
application
into
an
archive
so
that
it
can
be
loaded
somewhere
else?
This
is
equivalent
to
spiritually
equivalent
to
providing
bundling
providing
the
foundations
for
writing
a
bundler.
A
And
in
particular,
we've
written
a
tool
called
a
compartment
mapper
which
takes
node
modules
off
of
the
file
system
and
creates
an
archive
with
a
compartment
map
which
is
spiritually
similar
to
an
import
map,
except
that
it
puts
every
package
in
a
separate
compartment
which
is
spiritually
similar
to
scopes,
and
then
what
are
scopes
scopes
from
import
maps
and
import
maps?
The
scope
is
to
say
that
anything
underneath
this
url
prefix
is
associated
with
this
namespace
and
in
a
way
this
is
a.
A
This
is
effectively
an
an
alternate
take
on
how
to
implement
import
maps
in
user
space
and
the
way
it
works.
You've
seen
this
slide
before.
Maybe
I'm
hoping
that
we're
now
prepared
to
prepare
to
understand
what
each
of
these
stages
corresponds
to
the.
B
Rose
just
in
this
way
of
rendering
it
everything
up,
everything
up
to
the
slide
was
perfectly
legible,
but
this
way
of
rendering
it
is
making
this
slide
much
harder
to
read.
A
Okay,
let
me
attempt
a
last
minute
change
of
well.
Well,
here's
here's
one
way.
Let
me
see
if
I
can
fix
it
this
way.
A
No,
this!
This
is
no
no.
A
A
B
A
Okay,
so
the
the
way
this
works
is
each
of
the
columns
is
a
workflow
right
for
a
different
use
case,
and
each
of
the
rows
is
a
stage
that
some
that
each
of
these
workflows
may
or
may
not
need
so,
for
example,.
B
Let
me
interrupt
you,
I
think,
there's
some
bad
wrapping
here.
Import
archive
and
endowments
and
files
on
the
left
look
like
bad.
B
A
Yeah,
it
was
I
I
hastily
changed
the
slides,
and
this
is
some
some
inevitable
artifacts
of
creeped
in
the
okay.
So,
yes,
so
the
way,
the
way,
the
the
way
that
this
works
is,
for
example,
this
star
indicates
that
this
is
in
the
import
from
the
location.
Workflow
searching
for
the
searching
for
the
package
containing
the
module
is
a
step,
that's
necessary
right
and
then
to
import
import,
the
node
application
from
from
the
file
system.
A
The
first
step
that
we
do
is
we
map
all
of
the
package
jsons
that
we
find
into
the
corresponding
compartments
and
then
create
a
compartment
map,
a
json
file
that
describes
where
to
find
all
of
the
sources
and
how
to
assemble
them
into
a
working
application
and
how
to
link
the
compartments
together
since
every
package
gets
its
own
compartment.
A
This
is
the
step
where,
where
we
read
the
exports
and
imports
properties
of
the
package
jsons
and
create
the
corresponding
properties
in
the
in
the
compartment
map
and
because
node
is
not
fully
expressed
with
exports
and
imports
and
package
jsons
today,
it
also
fills
in
the
gap
there
for
inferring
with
those
inferring.
Those
cross
connections
with
an
import
map
hook,
and
then
we
go
on
to
assembling
the
compartments
into
and
the
pardon
from
the
compartment
map.
A
We
then
can
instantiate
compartments
and
connect
them
to
each
other,
which
I
call
assembly,
and
at
this
stage
none
of
it
has
not
executed
all
of
the
all
of
the
static
module
records
have
been
loaded
and
it
is
ready
to
execute.
But
it's
also
ready
to
pop
over
to
some
of
these
other
workflows
and
do
some
other
things
that
don't
involve
execution
anyhow,
then
you
load
the
compartments
and
import
the
modules
you
assemble
the
compartments.
A
Then
you
load
the
modules
into
the
compartments,
and
then
you
execute
by
calling
import
the
dynamic
import
on
your
entry
point,
and
then
loading
is
is
all
of
that
except
executing
which
allows
you
to
then
instantiate
your
compartment,
possibly
more
than
one
time
your
entire
graph
of
your
application,
possibly
more
than
one
time
it.
Just
it
just
curries
the
import
and
is
the
is
the
foundation
for
the
implementation
of
import.
Writing
an
archive
is
most
of
the
same
steps.
A
We
find
all
of
the
node
modules
off
as
a
file
system
and
we
assign
we
create
the
compartment
map.
B
So
the
the
thing
about
instantiating,
more
than
once
at
the
place
you
were
pointing
at
if
you
instantiate
a
given
static,
static
module
record
more
than
once,
you
need
to
be
instantiating
it
in
different
compartments.
A
A
B
A
Yeah
yeah
yeah
and
it's
yeah
we
can
revisit
that.
I
I
think
that
the
implementation
actually
I
I
think
that
my
description
misrepresents
the
implementation.
The
a
lot
of
things
are
deferred
to
import,
but
prepared
ahead
of
time.
Yeah
I'll
have
to
look
spiritually.
This
is
what
should
be
possible
and-
and
we
can,
we
can
iron
out
iron
it
out.
So
writing
an
archive
is
is,
is
the
I
the
process
of
writing
an
archive
is
finding
them
off
of
the
file
system
and
then
writing
to
a
zip
file.
A
In
our
case,
we
could
equally
do
the
same
thing
to
ipps
or
whatever,
but
the
idea
is
find
all
the
modules
off
the
file
system
put
them
in
compartment,
create
a
compartment
map,
assemble
them
and
load
them,
and
now,
because
of
that,
you
have
induced
the
induced
your
import
hook
to
to
capture
all
of
the
sources
that
you
need
to
put
in
the
archive.
So
we
put
it
in
we
pack
it
into
a
zip
file
and
then
write
it
in
the
process
of
packing
it
into
a
zip
file.
A
We
erase
the
knowledge
of
the
specific
layout
of
the
file
system
on
the
on
the
on
the
system
in
which
the
archive
was
created,
essentially
normalizing
them
into
a
zip
file
format
where
every
package
is
an
immediate
sub
directory
of
the
root
yeah
and
this
could
there
yeah
and
zip
files
are
okay.
There
are
all
you
could
you
could
do
the
same
process
and
and
put
into
a
content
address
store
like
git
or
into
ipfs
or
such,
which
has
some
other
advantages
over
this
approach.
A
Making
an
archive
is
everything
except
for
writing
it,
which
produces
a
I,
in
our
case,
a
typed
array
that
contains
the
the
data
that
would
be
written
to
the
archive
and
you
can
put
it
somewhere
else
if
you
wish
so
at
that
point,
you've
basically
taken
taken
an
application
off
of
your
file
system
and
put
it
on
ice,
so
it
can
be
executed
somewhere
else.
A
So
the
bytes
of
that
archive
can
flow
into
parse
archive
directly
and
which
point
you
just
read:
it
unpack
it
and
then
at
that
point
you
have
something
that
can
be
assembled
and
executed.
Pluses
indicate,
oh,
I
don't
even
remember.
That's
the
peril
of
not
writing
a
legend.
A
The
that
these
are.
I
think
that
my
intention
was
that
these
were
steps
that
were
deferred
that
are
deferred,
but
you
could
you
could
execute
them
with
a
follow-on
method
of
the
artifact.
You
got
from
the
end
of
this
step
right,
so
parsing
archive
gives
you
an
archive,
an
application
object
and
calling
import
on
the
application
object.
Takes
you
all
the
way
down
to
import
effectively
and
load,
not
so
much.
A
I
need
to
make
some
updates
on
here.
Import
import
takes
the
archive
and
executes
it
all
the
way
to
the
end
and
and
endowments
are
injected
here
and
parse
is
based
off
of
the
bytes
that
you
receive
from
make
archive,
whereas
load
and
import
are
based
off
of
the
files
you
put
on
the
file
system,
so
so
the
archive
flows
in
this
way
off
of
the
files
instead
of
through
bytes,
should
parse.
B
R5
not
have
an
asterisk
in
the
row,
read
archive
since
it
doesn't
have.
Since
it's
it's
it's
it's.
You
know
it's
coming
from
a
flow
that
did
not
have
an
asterisk
in
right
archive.
B
B
B
Right
and
parse
archive
parse
archive
is,
is
the
the
the
thing.
A
B
A
A
B
A
And
I'm
just
going
to
take
these
pluses
out
because
they
are
simply.
A
Yeah
load,
parts
and
load
both
give
you
the
same
thing:
they
just
come
from
different
origins,
yeah.
This
is
correct.
A
A
We
need
to
be
able
to
have
one
compartment
that
has
that
that
is
able
to
load
modules
from
another
compartment
and,
to
that
end,
we're
proposing
the
addition
of
a
module
method
on
the
compartment
object
on
compartment
instances,
which
would
give
you
the
name
a
proxy
for
the
namespace,
or
rather
an
exotic
object
representing
the
namespace
of
the
of
the
module
that
would
eventually
be
executed,
and
the
one
of
the
keys
about
this
is
that
it
you
can
do
this
before
you
have
loaded
the
module
it
before.
A
You
even
know
that
this
module
could
exist
in
the
compartment,
and
the
reason
for
doing
this
is
for
simplicity
and
the
api
is
that
we
are
the
compartment
compartment.
A
Api
already
receives
this
module
map
object
as
an
argument,
according
to
the
current
proposal,
and
it
accepts
in
its
value
place,
either
a
module
namespace
object
or
the
string
name
of
the
module
from
the
parent
compartment,
which
would
allow
you
to
take
sources
even
if,
even
if
there
isn't
a
static
module
record
involved
in
the
system,
as
is
the
case
for
moddable
success,
it
allows
in
excess's
case
the
way
you
get.
A
A
We
need
the
ability
to
to
do
cross
linkage
between
compartments
and
and
in
order
to
do
that,
we
need
a
mechanism
to
refer
to
a
module
that
will
be
loaded
in
another
compartment
and
there
are
variations
on
this
idea,
but
this
is
the
one
that
mostly
fits
with
the
existing
proposal
and
and
with
so
with
this
idea,
if
I
were
to
say
from
the
parent
compartment
load,
the
entry
point
module
which
I'm
suggesting
is
called
dot
in
this
particular
case.
The.
A
What
would
happen
is
that,
if,
if
the
the
the
import
hook
brings
in
a
static
module
record
for
a
module
that
requires
that
imports
something
called
dependency
as
a
as
a
full
specifier,
the
compartment
would
look
to
the
module
map
instead
of
the
import
hook.
A
To
find
that
dependency,
and
in
this
case
it
would
see
this
is
a
module
namespace
from
another
compartment,
and
it
would
go
and
ask
that
compartment
to
produce
to
produce
the
names
to
execute
the
namespace
of
that
module
and
and
thereby
make
it
available
to
the
dependency
in
this
compartment.
A
It
also
you
need
to
execute
the
names
first
into
pardon,
in
this
case
it's
affecting
the
load
not
to
the
link
and
execute.
I'm
sorry.
A
A
I'm
then
we
are
proposing
the
addition.
This
was
kind
of
implied
we're,
proposing
the
addition
of
a
static
module
record
constructor
to
the
to
the
proposal
and
the
static
module
record.
Constructor
is
it's
a
function
that
accepts
the
source
of
a
of
an
esm,
module
and
optionally
its
location
for
the
purposes
of
populating
the
exceptions
thrown
from
within
that
from
within
that
module?
A
It
occurs
to
me
that
this
actually
is
more
tightly
bound
than
we
want
it
to
be,
and
we
probably
need
to
remove
the
location
from
that
and
find
another
way
to
get
that
to
propagate
through
exceptions,
but
bear
with
me
as
I
do.
My
stunts
live.
The
the
the
intent
is
that
you
would
provide
a
load
hook
function
to
the
compartment
constructor.
A
This
load
hook
would
be
responsible
for
finding
the
location
for
a
particular
module
specifier
in
the
scope
of
that
compartment
and
then
retrieving
the
source
by
whatever
means,
by
whatever
means
the
source
can
be
obtained
in
that
compartment
and
then
constructing
a
static
module
record
for
the
source
at
that
location,
and
it
occurs
to
me
that
we
need
to
find
another
way
to
thread
the
location.
But
we'll
we'll
talk
about
that
offline.
I
think.
C
Separate
the
resolve
operation,
but
but
I
guess
you
you
have
this
problem,
because
you
don't
have
a
canonical
scheme
that
both
takes
into
account
the
compartment
and
the
result
specifier
within
the
compartment.
You,
you
kind
of.
A
A
The
idea,
I
believe
for
static
module
records
is
that
they
be
reusable
across
compartments
and
the
location.
The
location
is
not
necessarily
the
same
across
compartments
it
is.
It
is
in
practice
that
this
might
be
okay.
B
C
Are
you
intending
static
module
record
to
enable
bundling
use
cases
as
well
here,
or
is
that
kind
of
just
a
side
effect
of
this
proposal?.
A
In
the
bundling
use
case,
you
would
in
the
bundling
use
case,
you
would
probably
provide
a
load
hook.
That's
just
like
this,
except
that
before
returning
the
static
module
record,
it
would
write
the
source
to
a
side
table
and
note
where
I'm
from
I.
C
Guess
what
I'm
saying
is
if
you
say
that
portability
is
not
a
specific
issue
in
this
case,
that
the
existence
of
a
static
module
record
constructure
in
the
environment
means
that
you
can
create
ad
hoc
bundling
systems
using
it.
It
is
true
and
and
transform
systems.
So
it's
it's
quite
I
mean
it's
both
like
useful
things,
but
they're
important
aspects
of
its
implications
and
and
there
the
portability
question
should
also
be
considered.
A
Yes,
this
is,
this
is
where
you
would
conduct.
This
is
the
function
where
you
would
do
source
to
source
transforms
before
returning
a
static
module
record
and
that
and
you're
right.
This
is.
This
is
an
important
aspect
of
the
api
that
we
that
is
deliberately
present.
Do
you
foresee
objections
to
that
idea?.
C
C
I
I
guess
yeah
if
you've
got
two
versions
of
the
same
module,
that
came
from,
say,
a
static
bundle
and
or
some
collection
of
modules
that
was
pre-populated
and
you
you
want
two
different,
linked
versions
of
that
module.
You
might
not
necessarily
want
them
both.
So
if
location
can
affect
effectively
both
resolution
and
the
error
stack
or
is
it,
is
it
only
affecting
the
error?
Output
only
affects
the
error.
C
A
A
Truly
interesting,
yeah,
it's
response,
location,
but
cache
location.
A
A
This
wouldn't
be
the
mechanism
that
threads
import,
meta,
earl
or
any
of
the
other
metadata
the
there
is
in
in
in
the
proposal
as
bradley
has
written
it
today
there
is,
there
is
an
import
meta
hook
that
is
separate
from
this,
so
the
location
is
probably
yeah.
I
I
move
that
we
strike
location
from
this
from
this
api.
C
The
main
thing
was
just
as
long
as
it's
non.
You
know
like
like,
like
an
error,
stack
normally
that
the
information's
not
explicit
to
the
user.
So
it's
fine
as
long
as
the
same
sort
of
invariant
applies
here,
where
it's
not
something
that
that
users
can
sort
of
pick
up
and
start
using
is,
as
you
know,
as
though
error.
C
B
Yeah,
I'm
I'm
separately
very.
You
know
working
on
the
on
the
issue
of
jordan
and
I
have
a
proposal
for
error
stacks
and
with
the
also
work
I'm
doing
the
session.
B
I'm
definitely
interested
in
what
locations
are
shown
through
the
aerostacks,
but
I
think
I
think
we
don't
need
to
take
more
time.
I
think
we
can
note
that
this
is
an
issue
to
come
back
to.
A
Yes
sure
yeah
each
of
these
proposals
will
eventually
make
its
way
to
an
issue
on
the
proposal
on
the
tc39
repository
we
can
discuss
at
length.
A
And
okay,
so
that
got
us
ecmascript
modules.
It
does
not
get
us
linkage
with
any
other
third-party
module
system
and
it
is
to
be
this.
This
static
module
record
we're
turning
here
is
special
for
esm
and
does
allow
esm
style
linkage
and
because
of
that
it
it
hides
many
of
the
details
about
how
that
is
affected.
A
So
there's
sort
of
a
there
is
a
hidden
contract
between
static
module,
record
and
compartment,
presumably
in
the
specification
that
would
be
done
via
internal
slots,
but
there
is
no
user
space
mechanism
for
implementing
the
linkage
between
these
two
things
in
in
particular,
because
that
is
not
specifiable.
A
A
Okay,
so
I'm
proposing
that
we
add
a
third-party
static
module
interface,
that
is
to
say
you
can,
instead
of
returning
a
static
module
record
in
the
previous
slide,
you
could
return
a
record
object
that
implements
that
has
this
structure.
It
has
an
imports,
array
and
exports,
an
exports
array,
a
re-exports
array
for
export,
star
support
and
an
execute
method
that
receives
the
proxy.
A
The
internal
proxy
to
exports
object
and
the
compartment
originating
the
request
and
the
resolved
exports
for
the
court
that
corresponds
to
the
imports
array
in
the
context
of
this
compartment
right,
because
these
are
pre-computed,
there's
no
need
to
say
compartment.resolve
resolve
book,
which
is
not
even
possible.
This
is
just
with
this
api,
but
this
is
just
a
function
that
will
need
to
be
async
in
order
to
implement
top
level
of
weight
that
executes
the
body
of
a
module
either
a
common
js
module
or
a
webassembly
module
or
or
some
such.
C
Resolved
exports,
the
the
module
namespace
exotic
object.
A
A
Import
or
module
it
is
the
the
the
module
namespace
object
returned
by
module
and
import
is
the
exotic
module
namespace,
and
should
it
be
resolved
imports
on
the
far
right?
Yes,
it
should.
Yes,
yes,
yes,.
A
With
import
import
specifiers
here-
and
this
has
imports
the
corresponding
import
specifiers
as
keys
here
and
the
full
corresponding
full
specifiers
is
values.
A
Oh
well,
that's
handy.
Let's
mark
once
told
me
that
allen
k
had
a
saying
that
similar
things
should
either
be
the
same
or
recognizably
different,
you're,
muted,
mark.
A
Yeah
so.
A
So
what
we
ought
to
do
is
look
into
how
similar
this
is
to
what
webassembly
does
already
and
make
it
the
same.
I
think
okay,
so
the
way
this
would
look
is
that
in
a
compartment
you
would
write
an
import
hook
or
a
load
hook,
as
it
were,
that
free
returns
of
an
object
that
may
be
frozen.
That
has
the
imports
array
and
optionally
export
optionally,
the
the
exports
and
re-exports,
and
it
implements
execute
with
a
proxied
exports
and
the
compartment
in
the
resolved
imports.
A
A
So
next
topic,
I'm
proposing
that
we
add
a
module
map
hook,
option
to
the
compartment
constructor,
and
this
is
the
dynamic
fallback
for
the
module
map
argument.
The
idea
is
that
in
some
cases
you
can
know
what
the
module
map
up
front,
but
in
the
compartment
mappers
case
you
can't
or
pardon
the
compartment
mapper
for
implementing
node
does
not
allow
you
to
do
that,
because
you
do
not
know
all
of
the
modules
that
are
exported
by
another
compartment
by
looking
at
its
package.
A
Json
and
also
there
is
the
possibility
of
cyclic
dependencies
across
compartments,
which
also
is
not
possible
to
implement
if
the,
if
all
of
the
linkage
needs
to
be
known,
upfront
upon
construction
of
the
compartment.
So
the
module
map
argument
is
the
module
map.
Hook
is
a
fallback
so
provided
that
a
key
is
not
present
in
the
module
map.
You
can
look,
you
can
call
the
module
map
hook
and
if
it
returns
a
defined
value.
That
is
what
would
have
been
a
value
in
the
module
map.
A
As
a
reminder,
the
values
of
the
module
map
are
either
a
string
name
from
the
parent
compartment
or
a
namespace
object
from
from
this
or
another
compartment.
This
also,
incidentally,
solves
the
problem
of
of
aliasing
within
the
same
compartment.
You
can
use
this
to
implement
a
module
map
book
that
says
that
this
module
specifier
in
this
compartment
is
an
alias
for
another
module
specifier
and
the
same.
A
So
again,
this
helps
us
with
this
allows
us
to
do
aliases
within
the
same
compartment,
mutual
dependencies
between
modules
in
separate
compartments
and
linkage
to
modules
in
other
compartments
that
are
not
knowable
at
the
time
of
construction
of
the
compartment,
for
example,
files
off
of
the
files
in
node.js
packages
that
are
not
mentioned
in
package.json.
B
B
A
Which
is
not
something
that
we
necessarily
need
or
want,
but
something
that
falls
out
of
this
and
just
just
to
highlight
that
it
extends
the
possibility.
A
possibility
that
exists
today
within
a
compartment
becomes
possible
across
compartments.
With
this.
A
I
am
also
proposing-
let
me
move
my
things
around
and
that
we
removed
the
import
now
hook
from
the
proposal.
This
turns
out
to
be
vestigial.
The
import
hook
being
renamed
load
hook,
clarifies
that
these
are
from
separate
faces.
The
the
the
name
load
hook
now
is
contradictory,
loading
may
be
asynchronous,
importing
may
be
synchronous
and
any
necessary
loading
can
be
done
from
the
load
hook
and
any
necessary
executing
can
be
done
by
a
static
module
record.
So
this
is
simply
not
a
necessary
feature.
B
Okay,
I
think
that's
great.
This
has
been
in
particular
as
we've
been
presenting
this
to
other
audiences.
The
import
now
hook
has
been
a
repeated
source
of
resistance,
peter.
The
original
suggestion
for
import
now
hook
came
from
mautable.
B
Are
you
satisfied
that
this
way
of
refactoring
the
concerns
addresses
the
issues?
Sorry,
I
was
muted.
I
I
I
believe
you
that
it
addresses
the
same
issue,
and
I
acknowledged
that
it's
been
important
now
has
been
a
topic
of
some
controversy,
but
we
need
to
go
back
and
look
at
this
a
little
bit
to
see
what
the
what
the
impact
is.
Okay,
in
particular,
just
to
talk
it
out
a
little
bit
the
the
standard,
modable
configuration
and
tc53
configuration
where
everything
is
pre-compiled.
B
There
is
no
loading,
there's
only
a
world
that
already
starts
with
all
of
the
pre-compiled
modules
as
static
module
records.
So
the
fact
that
the
static
module
records
you
know
can
can
be
executed
immediately.
B
B
I
want
to
understand
what
it
ends
up,
looking
like
in
our
code,
and
there
is
there's
a
funny
in
between
edge
case
where
we
actually
do
sort
of
arguably
load
modules
at
this
point,
and
so
I
want
to
look
at
what
that
what
that
all
means,
but
I
don't
have
any
express
concerns
here
other
than
it's
it's
a
lot
to
absorb
at
once.
Okay,
okay,.
A
It
strikes
me
as
possible
that
if
that's
the
case,
there
might
be
a
need
for
a
load
now
book
and
this
could
be
reframed
as
a
rename,
but
it
would
be
nice
if
that
turns
out
to
not
be
possible,
pardon
not
to
be
necessary
but
yeah.
Let's,
let's
let's
discuss
further,
I
I
can
create
issues
for
this
so
that
we
can
have
an
anchor
for
a
conversation.
B
Sure
you
know
happy
to
look
into
it.
It's
it's
definitely
a
a
a
place
that
needs
to
be
tightened
up.
So.
C
Just
just
as
a
reminder,
you
say
there
that
importing
may
be
barring
top
level
await
and-
and
this
discussion
has
been
about
the
load
hook,
but
is
there
a
proposal?
Are
you
proposing
a
synchronous
import?
There
is.
A
A
current
proposal
for
an
import
now
that
is
a
synchronous,
import
right,
yeah,
which,
which
is
which
is
my
next
slide.
Thank
you
for
thank
you
for
the
segway,
so
top
level
await
has
some
ramifications
that
were
not
taken
into
account
in
the
original
proposal.
A
So
static
module
record
may
need
we.
We
may
need
to
surface
to
the
compartment
api,
whether
a
module
has
top
level
await,
or
not
so
to
in,
to
induce
it
to
behave
according
to
the
existing
specification,
which
is
I'm
not
sure
about
this.
I'm
not
sure
whether
I'm
not
sure
whether
the
compartment
needs
to
know
this
up
front,
but
it
may
be
necessary.
A
My
understanding
is
that
sub
graphs
of
the
module
system
that
are
all
synchronous
will
tend
to
will
will
not
be
executed
asynchronously
they
will
be
executed
synchronously,
so
it
may
be
necessary
for
the
compartment
api
in
order
to
implement
top
level
away
to
know
whether
a
module
record
corresponds
to
a
module
that
is
async
or
synchronous,
and
and
also
since,
since
a
particular
entry
point
may
or
may
not,
transitively
include
a
top
level
away.
A
It
may
be
possible
for
us
to
have,
for
those
special
cases,
special
cases,
the
ability
to
call
import
now
as
specified
today
and
still
get
the
the
the
namespace
populated
synchronously,
but
that
gets
a
little
ugly,
potentially
and
we'd
have
to
make
some
decisions.
We
we'd
have
to
make
a
design
decision
to
either
fold
import
now
into
import,
which
would
return
a
promise,
regardless
of
whether
it
was
executed,
synchronously
or
we
would
need
to,
or
we
would
need
to
have
an
import
now
and
return
return.
A
Maybe
return
a
promise
only
if
it
needs
to
be-
and
you
know
only
if
that
entry
point
closes
over
a
top
level
of
weight
in
its
transit
dependencies,
because
having
a
top
level
of
weight,
infects
that
module
and
anything
that
depends
upon
it,
that
it
will
need
to
be
imported,
that
the
import
function
will
need
to
return
a
promise.
A
For
that
case,
I
think
that
the
I
think
that
the
clearest
and
easiest
most
obvious
thing
to
do
from
an
end
user's
perspective
is
for
us
to
delete
import
now
from
the
api
and
always
and
have
the
import
method,
always
return
a
promise,
regardless
of
whether
the
whether
the
graph
executes
synchronously
or
not.
C
I've
got
two
counter
points
to
that.
If
I
can
briefly
interject,
if
you
don't
mind
yeah,
so
I
I
like
the
idea
that
you
could
get
some
kind
of
unification,
you
could
imagine
this
import
function,
running
completely
synchronously
for
a
sync
graph
and
that
integrates
with
the
spec.
C
Just
fine
I
mean
if
you
had,
but
you're
still
effectively,
if
elsing
the
whole
graph
and
and
you
it's,
it's
not
a
lot
of
rapid
code,
but
it's
still
wrapper
code
on
the
code
path
where
you're
gating
the
entire
import
process
to
throw,
if
there's
an
async
node
in
the
graph
that
information
should
already
be
available.
So
it
shouldn't
be
extra
traversal
to
get
it
since
we've
discovered
that
during
the
instantiation
phase,
but
the
difference
in
behavior
is
that
two
things?
C
Firstly:
are
you
going
to
if
you're,
if
you're
going
to
skip
running
the
the
task
queue.
C
Before
you
execute
your
code,
which
normally
you
would
run
the
task
queue
before
you
before
you
execute
when
you
import
and
then
secondly,
if
you're
not
going
to
do
that,
any
execution
errors
are
now
top
level
evaluation
areas
of
the
import,
as
opposed
to
promised,
rejections
potentially
and
those
two
might
be
semantically.
C
A
A
Okay,
now
I
can
I'm
I'm
convinceable
on
that
point.
There
are
a
lot
of
options
here,
so
I,
if
I
refrain
what
you're
proposing
you're
proposing
that
we
keep
import
now,
as
is
that
import
now
would
only
work
if
the
transitive
graph
contains
no
module.
A
That
has
top
level
of
weight
right
and-
and
this
is
fine-
because
this
is
fine,
because
the
caller
can
depend
upon
the
entry
module
and
its
transitive
dependencies
to
remain
to
be
it's
knowable
at
a
particular
snapshot
of
a
program
and
in
in
view
of
maintenance
of
that
of
that
system.
A
We
just
accept
as
a
community
that
having
a
module
that
it
does
not
use
top
of
level
of
weight
and
turning
it
into
a
module
that
does
use
top
level
await,
has
the
potential
to
break
any
of
your
dependencies
for
dependencies.
Excuse
me
any
of
your
transitive
dependents
who
are
using
import
now,
whereas,
if
you
were
to
use
import
or
dynamic
import
and
use
either
the
import
method
of
the
compartment,
the
dynamic
import
available
within
the
compartment
both
of
those
would
return
a
promise
regardless
and
be
resilient
against.
Such
change.
C
Yeah,
that
sounds
like
a
a
good
summary
of
it,
and
I
I
I
can
appreciate
that
the
transitive
dependency
problem,
but
in
the
same
way
that
a
transitive
dependency
turning
async
it'll
also
break
your
ability
to.
I
assume
you,
because
if
you,
if
you
really
do
want
synchronous,
if
you
want
to
obtain
the
module
instance
synchronously
you're
going
to
be,
then
you
won't
be
able
to
get
it
out
from
the
promise,
even
though
it
was
synchronous.
C
A
C
B
A
Cool
peter:
do
you
have
an
opinion
of
the
direction
we
should
go
for
top
level
of
weight.
B
No
that
one
I
haven't
looked
at
sorry
all
right
has
access
already
implemented
top
level
rate.
Yes,
it
has
and
it's
actually
actively
used,
and
so
it
works
fine,
so
it's
there
and
we
can
certainly
use
that
as
a
testbed
to
prototype
whatever
we
whatever
we
decide.
A
B
That
is
a
good
question.
We've
tested
it
in
the
context
of
test
262,
but
I
don't
know
if
we've
actually
tested
it
with
compartments.
That's
a
good
question.
A
Okay,
well,
let's
we'll
we're,
you
know
at
work,
we're
obviously
fiddling
around
with
excess,
we're
going
to
be
fiddling
around
more.
Maybe
we
can
answer
the
question
and
and
capture
that
some
more
we
are
running
low.
A
So
how
far
am
I
okay
we'll
resume
we'll
resume
it
another
time
there
are
just
a
few
more.