►
From YouTube: SES Meeting: Compartments with XS
Description
Kris gives a presentation on the agreement and open questions for the Compartment proposal as XS’s native implementation of dynamic module loading converges with the SES shim.
A
All
right
welcome
to
the
cess
meeting.
Today's
date
is
february.
16Th.
Our
agenda
has
a
single
topic
which
spilled
over
from
last
week,
which
is
a
presentation
on
the
evolving
consensus
between
the
cess,
shim
and
xs's
native
implementation
of
dynamic
module,
loading
from
which
I'll
be
presenting,
and
it
looks
like
that's
the
only
topic
today,
so
it's
possibly
a
light
meeting
depending
on
how
quickly
we
get
through
this
topic.
A
All
right:
well,
let's
I'll
share
my
my
slides.
A
Sharing
that
screen
all
right,
everyone
should
see
a
slide
that
says
compartments
access,
motivated
changes
is
that
up
for
everyone,
all
right,
cool,
all
right,
so
dynamic
module
loading
in
general.
A
This
is
this
is
the
uncontroversial
bit.
The
idea
is
that
the
compartment
constructor
will
accept
a
number
of
additional
things.
It
already
accepts
a
module
map
and
that's
the
that.
That's
the
a
highly
overloaded
mapping
from
module
full
specifiers
within
the
compartment
to
either
either
a
string,
in
which
case
it
refers
to
the
full
specifier
in
the
containing
compartment
and
that
and
thereby
the
static
module
record,
not
the
module
instance
of
the
the
containing
compartment
or
or
or
possibly
other
things.
A
A
Yes,
yeah
a
module
map
is
an
object,
and
if
that
object
is
incomplete,
it
falls
the
we
we
check.
The
module
map
hook
for
for
entries
for
for
static
module
records,
the
the
are
presumed
and
the
module
map
hook
is
synchronous,
notably
whereas,
and
the
resolve
hook
is
a
function.
A
That's
used
to
elevate
modules,
specif
like
import
specifiers
from
within
an
esm
module
to
the
corresponding
full
specifier
in
the
context
of
a
particular
compartment,
and
that's
all
part
of
keeping
the
coupling
loose
between
static
module
records
and
module
instances
since
full
specifiers.
A
The
the
referrer
of
the
referrer
module
specifier
for
a
static
module
record
varies
depending
on
what
compartment
it's
instantiated
in
and
then,
ultimately,
what
the
shim
calls
the
import
hook
that
we
agree.
We
would
like
to
call
the
load
hook,
which
we've
discussed
at
this
meeting
in
the
past
yeah,
so
the
load
hook
is,
is
the
key.
The
load
hook
is
what
does
all
the
dynamic
runtime
module
loading?
A
This
is
the
thing
that
allows
us
to
have
a
program
that
receives
code
at
runtime
from
somewhere
anywhere
really,
and
the
job
of
the
load
hook
is
to
take
a
full
specifier,
locate
the
corresponding
source,
construct,
a
static
module
record
from
the
source
and
and
return
it,
and
that
is
that
that
is
necessarily
asynchronous.
B
A
That's
correct,
yes
yeah,
so
the
load
hook
is
is
responsible
for
looking
at
the
module
specifier
and
making
that
decision,
yeah,
module,
specifier
and
information
and
per
compartment.
C
A
It's
a
it,
it
is
a
fallback
and
yeah.
A
A
Yeah,
starting
so
module
map
and
module
map,
looking
hook
being
for
synchronous,
lookups
for
static
module
records,
whereas
the
load
hook
can
be
asynchronous
and
of
course
all
of
these
are
memoized
in
two
tables
within
the
compartment,
one
of
which
is
a
table
for
static
module
records
and
the
other
is
a
table
for
module
instances.
A
C
A
A
Yeah,
so
part
of
that
is
motivated
by
access
in
particular,
because
not
every
because
there's
sort
of
tiers
of
usage
and
in
the
very
simplest
of
cases,
if
we
go
if
we
take
excesses,
the
mo
accesses
use
case
is
the
motivating
example.
A
It
does
not
need
a
dynamic
module,
loader
and
until
now
has
not
had
one
and
the
base
case
for
them
is
that
they
only
had
a
module
map
and
the
presumption
there
is
that
the
initial
compartment
of
the
initial
realm
of
an
access
program
closes
over
and
has
pre-compiled
all
of
the
module
static
module
records
that
it
will
ever
need
for
the
life
of
the
program.
A
Yeah
and
to
that
end,
the
the
primary
the
primary
usage
of
a
compartment
in
their
world
is
constricting,
having
a
compartment
and
then
within
a
child
compartment.
Constructing
a
new
compartment
that
only
receives
static
module
records
from
the
parent
and
the
static
module
record
doesn't
exist
as
a
real
thing
for
them.
They
refer
to
them
by
name
right.
So
if
you
had
a
pre-compiled
binary
that
had
a
whole
bunch
of
a
whole
bunch
of
compil
static
module
records
baked
into
it
pre-compiled
into
it,
they
aren't
even
necessarily
linkable.
A
In
the
initial
compartment,
you
can
create
a
child
compartment
that
gives
them
names
in
the
child
compartment
context.
Those
names
are
the
referrers
for
the
import
specifiers
in
those
modules,
so
you
can
basically
take
a
global
namespace
of
com
of
modules
and
then
partition
them
into
separate
compartments
where
their
mod,
where
their
import
specifiers
make
sense
and
then
instantiate
those
compartments.
But
the
prime.
A
But
the
primary
motivating
use
case,
as
I
recall
from
their
demo
of
the
light
bulb,
is
that
they
can
have
a
whole
bunch
of
native
built-in
modules
and
some
pre-compiled
modules
in
the
initial
compartment
that
have
full
power
to
do
anything
with
the
underlying
hardware.
And
then
they
can
create
a
child
compartment
that
attenuates
those
by
virtualizing
their
implementation
and
receiving
powers
from
the
parent
compartment.
A
So
they
can
present
the
exact
same
environment
that
they
received,
but
with
limitations
like
cannot
cause
seizures
or
cannot
burn
out
the
bulb
through
through
software
written
in
javascript,
which
is
compelling.
That's
not
what
we
that's
not
how
we're
using
compartments
at
agorik,
though,
and
we
haven't
implemented
that
feature
of
the
shim.
C
B
Let
me
maybe
maybe
something
I
can
say
that
we'll
clarify
a
static
module
record
is
something
that
reflects
the
a
module
source
in
a
standalone
way.
It
has
no
to
to
make
a
static
module
record
from
module
source
does
not
require
any
notion
of
context
or
any
consulting
of
other
modules,
so
its
own.
So
the
the
the
static,
the
the
static
graph
is
a
static
graph
that
needs
to
be
calculated
well
after
you've
reduced
everything
to
static
module
records.
C
Okay,
so
the
idea
is
you're
parsing
module
records
for
some
identifiers.
You
may
not
be
able
to
have
the
stack
module
records
synchronously,
but
that
is
fine
as
long
as,
ultimately,
you
can
get
the
whole
all
the
module
records
and
every
identifier
that
our
reference
and
then
at
that
point-
and
at
that
point
that's
the
instantiation.
That's
synchronized,
okay,
yeah.
A
Yeah,
so
every
loader
has
two
two
delineated
phases
and
it's
basically
there's
an
async
phase
and
a
sync
phase,
and
within
the
async
phase
you
can
you
can
do
async
fetch.
You
can
do.
I
o
you,
can
parse
static
module
records
and
then,
with
the
result
of
parsing
a
static
module
record,
you
can
obtain
information
about
its
shallow
dependencies.
A
So
in
the
in
the
async
phase,
we
parse
pre-compile
and
collect
the
transitive
dependencies
of
the
working
set
for
for
a
particular
initialization
phase,
and
then,
once
you
have
the
entire
working
set
loaded
as
a
graph,
then
you
switch
and
then
begin
the
initialization
phase,
which
involves
linking
and
linking
all
of
the
creating
instances
of
all
the
modules
linking
them
and
then
initializing
them
in
order,
and
that
is
synchronous,
modulo
top
level
of
weight
which
is
yeah
so
moving
on
top
level
weight
is
not
implemented
by
the
shim.
A
We've
decided
not
to
ever
implement
it
in
the
shim,
but
excess
implements
top
level
of
weight
and,
and
the
reason
we're
comfortable,
not
implementing
it
in
the
shim
is
that
we
should
get
sufficient
feedback
from
the
implementation
in
excess
in
order
to
vet.
What
we're
proposing
to
tc39.
C
I
have
two
follow-up
questions
on
this.
Actually,
what
is
the
purpose
of
the
module
map
hook
and
maybe
somewhat
related?
Is
the
load
hook
allowed
to
mutate?
The
module
map.
A
The
load
hook
is,
is
allowed
to
modif
to
wait.
No,
the
module
map,
as
as
no
it
does
not.
The
module
map
is
captured
once
a
snapshot
of
the
module
map
is
captured
once
up
front
and
and
that
object
is
not
modified
at
runtime.
The
the
received
object
is
not
modified
at
runtime.
A
With
the
exception
of
the
fact
that
it
is
able
to
draw
a
static
module
record
in
from
the
surrounding
compartment,
that's
the
one
thing
it
can
do
that
a
little
hook
can't
and
poss,
and
there
are
possibly
other
things
because,
as
you'll
note
in
the
top
bullet
on
the
right
there
are,
we
still
have
open
questions.
A
We
need
to
go
back
with
excess
on
regarding
redirects
meta
and
third-party
module
records,
which
I
will
cover
in
subsequent
slides,
but
we're
proposing
to
make
to
add
support
for
those
in
the
load
hook,
but
not,
and
maybe
even
the
module
map
we
would
like
to.
We
might
not
be
able
to
bradley.
D
A
Okay,
well,
we'll
come
back
to
the
resolve,
hook,
implications
for
the
web.
That
sounds
great
eager
for
that
feedback.
Really.
So
so
this
is
what's
changed
well
or
what
remains
what
what
remains
to
become
consistent
between
the
shim
and
access
for
static
module
records,
one
one
difference
that
they
did
in
their
implementation.
So
the
static
module
record
constructor
is
like
the
function
constructor
in
the
sense
that
it
receives
source
as
an
argument
and
returns,
an
opaque
object.
A
Well,
we're
proposing
to
dc39
either
to
return
an
opaque
object
that
can
be
returned
in
load,
hooks
and
module
maps,
and
the
difference
in
the
implementation
in
excess
is
that
they
made
it
so
that
it
receives
a
record
and
then
it
overloads
its
behavior
based
off
of
what
the
shape
of
the
record
it
receives
between
first
party
and
third
party
static
module
records,
so
in
our
shim
the
load
hook
can
return
an
arbitrary
object
of
the
shape,
imports,
exports,
re-exports
and
execute,
and
that
will
be
interpreted
as
a
third-party
module
record
and
if
it's
instant,
if
it's,
if
it
matches
the
shape
of
a
static
module
record
it'll,
be
treated
as
first
party
for
reasons.
A
I
I
I
for
for
reasons
that
I
am
inferring
access
decided
to
make
it
so
that
first
and
third
party
static
module
records
most
must
both
go
through
the
static
module
record
constructor.
I
think
their
reasoning,
for
that
is
that
they
want
it
to
be
instance,
of
static
module
record
and
identify
and
distinguishable
from
other
types
based
off
of
that,
based
off
of
its
instance
of
check
based.
A
Possibly
the
latter,
I
don't
know-
and
I
think
that
this
has
implications
for
what
you
can
do
in
a
module
map.
The
idea
is
that,
if
the
value
in
a
module
map
is
a
string,
it's
a
reference
to
the
parent
compartment
static
module
record
map.
If
it's
an
object,
then
there
are
possibilities.
It
could
be
a
first
party
or
third-party
static
module
record
and
we
in
the
shim
distinguish
those
structurally.
A
I
think
that
they
would
like
the
ability
to
do
so
by
a
brand
check
or,
or
instance
of
check.
A
Party
yeah,
so
a
first
party
static,
module
record
is
a
static
module
record
that
refers
to
esm
source.
A
third-party
static
module
record
is
how
we
get
common
js
support
in
or
json
or
other
things
and
third-party
static
module
records
would
be.
It
would
allow
you
to
would
allow
you
to
do
those
things
like
common
js,
but
it
we
have
decided
so
far
that
it
is
not
necessary
for
third-party
static
module
records
to
participate
in
lazy,
late
lazy,
binding.
A
B
So
what
another
one
to
to
mention
there
is
wasm.
Wasm
also
does
not
support
live
bindings,
and
it
would
be
not
a
requirement
but
an
interesting
test
of
the
generality
of
what
we're
defining
here.
Whether
wasm
modules
could
simply
be
linked
in
as
a
third-party
static
module
records.
A
Yeah
and
then
the
other
difference
here
is
that
you'll
note
that
the
shape
of
the
description
of
a
third-party
module
record
is
different
in
access,
and
we
have
decided
to
converge
on
what
they
did
for
reasons.
I'll
talk
about
so
you'll
note
that
we
were
using
a
convention
of
having
arrays
and
maps
of
imports,
exports
react
exports
and
an
execute
function.
I
wanted
to
rename
execute
to
initialize
in
order
to
more
closely
match
the
match.
A
The
terminology
usually
used
in
262
for
module
initialization
and
the
difference
that
they
propose
is
that
instead
of
imports,
exports
and
re-exports,
they
would
like
us
to
produce
to
have
the
static
module
record
represent
the
bindings
with
an
array,
an
array
of
objects.
That's
that
that
closely
resemble
the
syntax
and
the
order
in
which
import
declarations
exist
in
the
syntax
of
the
under
of
the
implied
esm
module
behind
the
third
party.
A
Module
record
and
matthew
made
the
very
good
point
that
if
we
use
this
as
the
the
representation
we
can,
we
can
infer
the
imports,
exports
and
re-exports
maps
from
this.
But
we
cannot
do
the
reverse
without
losing
information
about
order
and
information
about
order
is
presumably
important
for
top
level
await.
B
A
Yeah
is
that
right
bradley
would
the
order
matter
for
top
level
await.
I.
B
It
doesn't,
but
the
order
does
matter
for
the
order
in
which
a
modules
is
initialized
right.
B
D
D
Well,
that's
what
the
spec
is
doing
when
you
initialize,
or
I
think
we
changed
it-
to
link
these
days.
A
source
text,
module
record.
B
A
In
in
this
particular
constitution,
context,
initializes
a
function
that
corresponds
to
executing
the
body
of
the
module
from
end
and
the
evaluation.
B
D
B
B
Chris,
regarding
naming,
I
don't
think
we
should
take
262
as
precedent
for
naming
anything
we
should.
You
know.
262
is
only
basically
us
communicating
with
ourselves,
and
we've
made
some
really
terrible,
terrible
terminological
choices
that
we
can
justify.
Only
because
we're
not
imposing
them
on
anyone
but
ourselves,
but
as
soon
as.
D
B
What
does
it,
what
thing
does
it
do?
Does
it
execute
rousm
code.
B
B
B
I
think
instantiate
is
a
is
a
fine
candidate,
because
we
talk
about
module
instances,
and
this
is
the
step
that
has
to
run
to
turn
this
the
static
notions
into
a
you.
Don't
get
a
module
instance
until
this
step
happens.
A
So
that's
for
one
not
true,
because
because
of
cycles.
A
D
So
adding
confusion
here,
webassembly
dot
instantiate
is
a
method
which
just
reading
a
quote,
performs
both
compilation
and
instantiation.
In
one
step.
B
B
If
I
remember
correctly,
the
the
way
it's
specified
is
such
that
an
implementation
can
pre-compile
things
as
long
as
it
pre-compiles
things
using
a
separate
compilation,
discipline
or
you
can
defer
a
compilation
to
instantiation,
in
which
case
you've
got
the
linkage
graph
and
you
can
do
cross
cross
instance.
B
You
know
compilation
and
linkage
decisions,
but
the
I
think
they
should
have
you
know,
given
that
they're
allowing
implementations
to
do
both.
I
think
it
would
have
been
cleaner
to
specify
it
as
if
separate
compilation
is
going
on,
but
they're
trying
to
be
closer
to
what
they
want
implementers
to
do,
but
any
case
their
module
corresponds,
semantically
to
our
static
module
record
and
their
module
instance
corresponds
to
our
module
instance.
D
Give
me
a
second
because
there
is
a
thing
that
probably
gets
executed
at
the
start
of
instantiating
the
web
assembly
module
yeah,
there's
like
a
underscore
start
equivalent
in
there.
Here
we
go.
B
D
A
Let's
come
back
to
this
after
we
have
a
better
understanding
of
the
signature
of
what
I
propose
is
called
initialized
initialize,
which
I
believe
is
soon
yeah
here.
It
is
so
in
a
third-party
static
module
record
we
previously
in
what
we
currently
have
implemented
in
the
shim
is
that
you
get
an
internal
representation
of
the
module
exports
namespace
of
that
module,
and
this
is
the
this-
is
the
object
that
can
be
modified
from
within
the
module
that
can
set
the
exported
names.
A
We
also
passed
on
the
compartment
and
import
to
full
specifier
mappings,
which
the
import
to
full
specifier
mapping
had
to
be
constructed
during
the
the
during
the
load
phase
and
there's
no
sense
in
having
not
in
doing
that
again
during
the
initialization
phase.
So
my
notion
was
that
you'd
use
compartment
and
and
import
now
in
order
to
emulate
common
js
and
the
ways
around
that
in
the
it
was
this
was.
A
This
was
clearly
not
right
in
a
number
for
a
number
of
reasons,
and
the
folks
at
moddable
came
back
with
this
signature.
For
the
initialize
function,
where
it
receives
the
module
environment
record,
I
don't
know
whether
this
is
named
in
the
spec
yet,
but
it
is
a
good
name.
A
This
is
an
object
that
represents
the
namespace
internal
to
the
module
that
the
module
can
set
values
on
and
it
enforces
rules
like
well,
it
actually
doesn't
enforce
any
rules,
but
it
has
all
of
the
names
that
are
imported
and
exported
in
that
module.
So
you
can
use
this
both
to
obtain
the
named
values
from
your
imports
and
set
the
named
values
of
your
exports,
and
they
are
the
internal
view
of
those
names.
So
if
there
is
an
as
marker
on
one
of
the
bindings,
this
is
the
this
will.
A
This
will
show
the
correct
name
in
from
the
perspective
in
the
internal
of
the
module,
whereas
the
module
namespace
object,
which
would
show
the
exported
name
and,
and
then
the
meta,
so
we
didn't
we
didn't.
We
have
not
solved
meta.
We
have
in
the
proposal
as
written
today,
a
notion
that
we
will
add
an
import
meta
hook
and
after
a
great
deal
of
discussion,
we
have
decided
that
that's
not
a
good.
Well,
it's
a
it's
a
fine
idea,
but
it's
not
it's
not.
A
It
doesn't
stand
the
the
it
doesn't,
stand,
scrutiny
and
I'll
explain
in
the
next
slide.
The
other.
The
other
part
about
this
is
that,
in
order
to
support
top
level
await,
the
initialize
function
should
be
an
async
function.
If
it
has
top
level
await,
and
it
should
be
a
synchronous
function
if
it
does
not
use
top
level
away,
because
that
information
needs
to
be
knowable
that
needs
to
be
knowable
before
initialization
begins
in
order
to
figure
out
the
initialization
order.
A
In
this
case
it
we
will
need
an
explicit
marker
either
by
signifying
it
on
the
prototype
by
choosing
which
prototype
the
function
inherits
from
either
async
function
or
function
or
or
have
another
marker
on
the
third
party
module
record.
That
expressly
indicates
whether
it's
async
or
not,
the
entity
that
needs
to
know.
I
forget,
I
forget
which
one
it
is
it's
either
the
linker.
A
B
Okay
yeah,
if
obviously,
if
the
constraint
you
stated,
is
a
constraint
we
need,
then
we
can't
simply
distinguish
on
that
basis.
But
if
it's
not,
if,
if
that
constraint,
doesn't
turn
does
doesn't
turn
out
to
be
a
necessary
constraint,
that's
certainly
my
preference
is
to
do
it.
Matthew
suggested,
because
then
we
maintain
the
the
general.
B
A
Yeah
I
I
agree
that
that
would
be
ideal,
and
that
would
be
a
good
question
for
the
model
folks
because
they
definitely
know
the
answer
already,
since
they
have
top
level
weight
implemented
already.
A
A
In
order
for
import
now
to
throw
an
exception,
if
the
the
module
in
question
can't
be
initialized
synchronously
that
for
that
it
needs
to
be,
we
need
to
know
up
front
whether
the
entire
subgraph
is
synchronous.
B
Why
can't
you
throw
the
exception
if
any
of
the
modules
return
a
promise.
A
That
that's
just
a
difference
in
semantics:
it's
do.
We
want
to
allow
for
the
possibility
of
partially
initial
partial
initialization
of
of
the
of
the
subgraph
in
the
case
where
it
can't
be
completed.
B
A
Yeah,
okay,
so
I
think
we're
in
agreement.
We
are
in
agreement
that
if
no
indication
is
necessary,
that
is
ideal
if
an
indication
is
necessary
having
it
explicit
on
the
third
party
as
a
property
of
the
third
party,
module
record
is
an
option,
and
if
it's
a
pardon,
that's
the
last
option,
the
fir
the
the
next
best
is.
A
Can
we
just
run
it
and
then,
if
it
returns
a
promise,
then
then
it's
been
treated
as
async,
but
I
think
yeah
and
and
and
this
and
whether
we
care
about
this
for
the
purposes
of
tc39
versus
an
allowable
variation
of
xs
is
another
matter.
C
A
Record
is
just
is
analogous
to
the
module
namespace
exotic
object.
It
is
a
different
exotic
object.
Viewing
the
the
same
underlying
data.
A
It's
like
the
module
namespace
object
in
the
sense
that
it's
an
object
of
probably
an
almost
certainly
an
exotic
object
that
you
can
read
properly
so
module
namespot
space
object
is
read-only
if,
unless
I'm
mistaken,
internal
version
of
that.
C
What
I
was
wondering
is,
can
the
oh,
this
is
only
for
third
third-party
modules,
so
it's
not
for
okay,
gotcha.
A
Yeah
yeah,
so
if
a
common
gs,
yeah
common
js
linkage,
is
a
problem
that
zbjec
is
working
on
for
us
right
now,
so
we
do
not
have
we
don't.
A
We
don't
yet
know
exactly
what
this,
what
what
a
common
js
initializer
is
going
to
look
like,
but
it's
complicated
on
the
account
of
having
to
both
support
all
of
the
most
as
much
of
the
common
js
world
as
possible
on
top
of
this
loader,
but
also
also
being
able
to
accommodate
the
the
dunder
es,
module,
property
and
yeah,
and
attempting
to
approach
parity
with
the
current
implementation
of
node.
A
One
thing
that
this
this
will
allow
that
node
does
not
is
bi-directional
linkage
between
common
gs
and
esm,
which
is
a
standard
non-goal
for
node.
A
Yeah
for
for
node
reasons
that
are
good
but
but
do
not
need
to
be
perpetuated
by
our
implementation.
There
doesn't
need
to
be
an
underlying
synchronous
loader
for
our
api.
A
Yeah,
so
the
other
thing
that
we
talked
a
lot
about
was
meta.
We,
the
shim,
does
not
currently
have
a
solution
for
surface
or
the
arc,
and
the
proposal
as
a
provisional
import
meta
hook.
But
my
observation
is
that
all
of
the
information
you
need
in
order
to
construct
the
meta
object
for
a
particular
module
for
one
can't
be
on
the
static
module
record,
because
it
varies
based
off
of
the
instance
in
the
compartment.
A
A
So,
as
bradley
has
pointed
out
multiple
times
in
the
past,
the
web
and
node
both
set
the
meta
url
to
the
response,
url
that
was
that
was
obtained
through
fetching
the
record
now
over
over
http.
That
means
that
you,
you
might
fetch
a
request
url,
but
if
it
follows,
redirect
you're
going
to
get
a
response
url
and
you
want
the
import
meta
url
to
correspond
to
the
response
url.
A
That
means
that
knowing
what
to
put
in
meta
is
a
side
effect
of
loading.
So
what
what
we've
arrived
at
is
that
the
load
hook
will
return
an
envelope
around
the
static
module
record
in
the
case
where
it
can
provide
meta
information,
so
static,
module
record
is
an
accepted
return
value.
In
the
simple
case,
if
and
by
default,
the
meta
object
will
be
empty.
A
A
Then
we
would
add
properties
of
the
of
the
given
meta
object
to
the
import
meta
object
of
the
of
the
module
that
would
be
received
by
initialization
of
that
module.
So
the
meta
that
you
see
here
as
a
second
argument
to
initialize
would
be
carried
in
this
way
from
the
load
hook
to
initialization
everyone
with
me
so
far
because
it
gets
weirder.
D
D
There's
a
interesting
oddity.
However,
most
engines
do
not
actually
create
the
meta
object
until
it
is
accessed,
and
since
it
is
not
available
in
eval,
it
is
statically
knowable.
If
you
actually
ever
want
to
create
it.
D
B
A
A
Yeah
all
right.
Well,
I
think
that
that
none
of
that
comes
to
bear
on
this.
The
idea
for
us
is
that
we
would
copy
the
properties
of
this
onto
whatever
the
meta
instance.
Whenever
the
meta
instance
is
created.
A
Unless
it's
really
really
really
compelling
in
order
for
it
to
be
late
and
in
order
for
them,
the
contents
of
the
meta
object
to
be
very
late
created
at
a
late
stage,
and
that
is
probably
the
motivation
bradley's
is
getting
at,
because
it
is
expensive
to
construct
a
meta
object
that
cons
that
contains,
for
example,
a
resolve
function,
and
if
you
can
avoid
that
work,
it
would
be
great.
I
am
not
inclined
to
care
personally,
but
is
that
is
that
is
that
the
case
bradley.
D
So
the
web
is
trying
node
in
the
web
are
bickering
a
little
bit
about
if
the
web
should
ship
import
matter
resolve,
but
the
more
the
more
properties
you
put
on
this
thing,
the
more
expensive
it
is
so
because
these
are
still
going
to
be
null
prototypes,
so
you're
going
to
have
a
closure
generally
associated
with
any
function
you
put
on
it.
B
So
this
being
early
days,
I
suggest
that
we
should
go
ahead
and
not
initialize.
It
lazily
create
it
eagerly
up
front,
because
that
will
be
a
disincentive
to
piling
lots
of
stuff
on
it.
A
What
we
could
do,
what
we
could
do
is
later
add
an
import
meta
hook
that
elaborates
or
embellishes
the
meta
object
based
off
of
the
data.
That's
on
it
already.
That
would
probably
be
sufficient
to.
That
would
probably
be
sufficient
to
address
the
question
of
lazily.
Creating
a
closure
object
on
every
module
make
it.
A
A
The
the
meta
that's
returned
by
the
load
hook
could
do
could
could
could
add
a
resolve
function
to
the
meta
object
but
doesn't
have
to
it
could
be
deferred
in
the
cases
where
there's
a
performance
concerned,
we
could
add
an
import
metahook
that
received
that
only
receives
the
existing
meta
object
and
can
embellish
it
with
a
resolve
function
of
resolve
closure,
and
we
would
only
call
the
import
meta
hook
if,
if
the
meta
is
ever
accessed
by
client
code.
A
A
B
B
The
first
time
that
causes
the
hook
to
be
invoked
and
then
once
there's
a
meta
object.
It
can
just
be
a
plain
object
that
satisfies
these
constraints.
A
Right
and
the
import
right.
You,
though,
I
don't
think
that
you
can
actually
capture
the
import
meta
object.
Can
you
I've
never
tried?
I
think
you
can
only
get
properties
off
of
it.
A
Got
it
all
right
so
but
yeah
with
some
constraints
on
what
it
can
be
yeah?
Okay,
so
we
can't
return
an
arbitrary
thing
in
this
meta
thing.
It
really
has
to
be
a
bag
of
properties
that
get
copied
onto
an
object
that
has
a
null
prototype.
A
A
A
In
that
case,
I
discovered
quite
accidentally
for
lack
of
forethought
that
the
module
referrer
specifier
of
that
module
needs
to
be
source,
slash
index,
not
dot,
otherwise
its
import
specifiers
are
not
resolvable.
So
what
this?
What
the
redirect
module
record,
which
we
have
implemented
in
the
shem,
although
we
have
not
implemented
meta,
allows
us
to
to
express
hey
you,
you
attempted
to
load
dot,
you
actually
got
dot.
Slash
index.js
here
is
the
corresponding
meta
or
static
module
record
for
for
that
module,
and
that's
what
this
feature
is.
C
B
C
Right,
so
what
I
mean
is
that
if
we
provide
a
module
map,
if
user
code
provides
a
module
map
when
creating
compartments,
there
are
questions
about
what
the
identifiers
use.
There
should
be.
A
And
so
it
is
important
that
this
that
the
specification
for
compartments
be
flexible
enough
to
handle
to
to
handle
the
access,
use
cases.
The
web
use
cases,
the
node
use
cases
and
hopefully
use
cases
we
have
yet
to
dream.
D
So
throwing
some
wrenches
the
redirect
string
is
that
absolute
is
it
meant
to
be
a
cash
key.
D
D
D
A
A
It
will
have
to
just
part
you
know
in
order
to
get
import
assertions
implemented,
it
will
have
to
participate
in
the
cash
key
yeah
and
we're
at
time
as
alex
points
out
and
which
is
good,
because
this
is
my
last
slide
that
thank
you,
everyone
that
turned
out
to
be
a
much
fuller
topic
than
I
expected
and
I'll
be
sure
to
share
this
with
our
friends
at
modible.
C
Recording
I
still
wanna
see
how
this
whole
meshes
up
with
module,
fragments
and
module
blocks.
Yeah.
A
Yeah
yeah
yeah.
Well,
I
think
that
the
questions
that
we're
answering
here
regarding
redirects
and
meta
and
those
things
need
analogous
answers
when
it
comes
to
module,
fragments
and
blocks.