►
From YouTube: SES-mtg: Compartments + Module reflection for loading
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).
B
B
Some
of
them
are
possible
to
be
soft
today.
Some
of
them
are
not
the
three
features
that
I
believe
are
important.
Our
first
one
is
if
I'm
importing
a
module,
how
can
I
control
how
to
resolve
the
the
source
that
that
this
module,
that
I
am
importing
represents
basically
what
the
what
you
could
achieve
today
with
the
import
Maps?
So
if
I
have
a
in
permit
that
describe
when
this
module
try
to
import
this
module
specified?
This
is
where
you
can.
Okay,
so
right.
B
Okay,
the
mapping
of
that,
okay
and
and
and
as
I
said
this
particular
case
for
browsers.
There
is
a
solution
for
note:
there
is
no
solution
and
obviously
for
the
evaluator,
which
have
a
way
to
hook
into
that
process
in
a
way
that
we
could
act
as
a
resolver
of
some
sort.
That's
just
a
defining.
What
kind
of
relationship
there
is
between
the
info
are
important
in
terms
of
resolution.
B
B
A
B
And
it's
not
might
very
well
be
compartment,
and
then
the
last
one,
which
is
the
one
that
I
was
trying
to
explain
last
week,
is
the
ability
for
us
to
control
what
what
this
module
is
accessing
from
mm-hmm
and
and
I
feel
like
that's
the
one
that
was
missing
from
the
front
they
from
both
proposals.
They
they
they
proposal,
you
percent,
and
they
the
notes
that
I
show
last
week.
B
And
apply
certain
rules
to
what
this
module
is
capable
to
do,
and
if
we
say
that
the
rules
are
defined
at
the
component
level,
you
can
create
a
component
for
it
and
evaluate
it
into
a
compartment.
I
do
believe
that
that's
not
sufficient,
because
the
component
is
sharing
intrinsics
with
a
bunch
of
other
people.
Unless
that
those
are
frozen,
then
you
have
issues
with
it
and
such
so.
The
compartment
for
me
is
not
a
sufficient
encapsulation
to
feel
comfortable,
saying.
Oh,
you
want
to
just
contain
something
that
the
modules
try
to
do:
throw
a
contaminated.
A
So
there's
so
it's
not!
That
compartments
mean
that
we
don't
have
realms
anymore.
Obviously,
if
you
want
a
different
set
of
intrinsics.
Well,
that's
what
the
realms
proposal
is
about,
but
within
a
given
set
of
intrinsics
sharing
a
given
set
of
intrinsics,
you
still
need
to
be
able
to
create
separate
compartments
with
separate
Global's
with
separate
import,
namespaces
etc.
So.
A
A
A
B
A
B
Unless
that
I
are
a
extra
indirection
of
some
sort,
I
will
be
effectively
accessing
the
code
that
is
running
in
a
different
ground
in
a
different
compartment
inside
around
maybe
even
I
mean
and
now
I
have
a
direct
access
to
that
thing.
That
is
on
trust.
That
is
not
trusted.
So
there's
no
there's
no
way
for
me
to
introduce
a
membrane
in
between
these
two
sides.
Well,.
A
There
I
mean
there
is,
depending
on
what
controls
we
provide
over
the
the
remapping
of
the
important
space,
so
the
in
the
case,
so
we
didn't
quite
be
the
the
it
wouldn't
have
it
would
have
to
have
additional
mechanism
beyond
the
membranes.
As
we've
talked
about,
we've
talked
about
how
for
a
given
module,
you
can
create
an
attenuating
module
that
that
reacts
that
imports
and
reacts
ports
the
contents
of
that
module.
So
you
can
think
of
that
as
a
sort
of
module
level.
Extension
of
the
main
threat
of
the
membrane
concept.
B
Right,
but
that
doesn't
that
doesn't
they
attenuated
module
does
not
have
like
my
knees
anymore,
because
you
there's
no
way
you
can
describe
you're
getting
something
from
the
untrusted
source,
wrap
it
into
a
membrane
and
export
it
to
you.
What
happened
when
that
or
in
are
untrusted
changes
the
the
export
value
you
sign
up
for
that,
and
therefore
you
don't
have
a
way
to
re-explore
that,
so
you
were
missing
semantics
of
the
module
system
without
generated
module
in
between
okay.
A
There's
no
generic
way
to
say
I
want
to
react.
I
want
to
export
this
object,
as
my
module
name
space
object.
So
if
you
can
import
a
module
name,
space
object
from
another
module,
but
if
you
then
wrap
it
in
a
proxy,
you
can't
take
a
proxy
for
a
module
name.
Space
object
and
export
it
as
your
own
module
name
space
object.
If
you
could,
that
would
be
a
generic
mechanism
for.
A
B
A
A
A
It's
as
if
the
module
name
space
object,
has
a
getter
property
that,
whenever
access
just
gets
the
correct
value
of
the
variable,
so
by
exporting
the
variable,
what
you're
really
doing
is
you're
is
you're
exporting
a
getter
that
will
repeatedly
get
the
variable
so
that,
and
that,
of
course,
will
work
for
a
proxy
just
fine
with
regard
to
the
initialization
logic.
I,
don't
know
right.
B
A
A
So
so
the
gorak
translation,
that's
trying
to
run.
You
emulate
a
module
system
on
top
of
the
width
on
a
proxy
trick.
So
that's
using
the
width
on
a
proxy
scope
bindings
in
order
to
emulate
Y
bindings.
Yes,
but
we're
with
regard
to
what
we're
trying
to
propose.
We
want
it
to
post
something
that
it's
not
using
a
with
yeah.
C
A
C
A
Create
a
variable
that
represents
somebody
else's
life
binding,
it
seems
like
you,
can
do
the
same
thing:
to
create
a
local
variable
that
represented
a
getter
that
was
obtained,
such
that
whenever
you
read
the
variable,
you
were
really
invoking
the
getter
and
yeah.
You
tried
to
assign
the
variable
and
you
got
an
error
so.
B
They
from
what
I
remember
the
NEMA
space
up.
Gate
is
not
even
create
when
it
comes
to
evaluating
modules
or
depend
the
pendency
between
modules,
because
those
dependencies
are
resolved
directly
to
the
environment
environment
record
of
each
of
the
modules.
The
anemic
space
is
only
used
if
you
are
accessing
a
namespace
occupy
importing.
A
namespace
object
is
now
used
as
a
linkage
between
modules
at
all
and.
C
C
B
Didn't
quite
get
what
you
so
I,
don't
think
we're
proposing
changing
any
of
the
dynamics
of
how
things
work
today,
so
the
parser
will
still
parse.
The
parser
will
still
give
you
the
same
error,
saying
you
have
a
less
declaration
for
a
binding
that
you
are
also
important
and
it
will
give
you
the
same
error.
It's
only
when
the
the
code
that
is
being
evaluated
inside
the
module
is
attempting
to
access
the
the
binding
called
foo
or
is
using
foo,
and
it
needs
to
be
resolved
when
this
process
of
resolving
foo
it's
going
to
happen.
B
C
Yeah,
so
I
was
just
contrasting
from
experimenting
with
the
width
approach,
so
with
the
with
approach,
the
problem
that
I
could
not
get
the
Yi
with
closure
to
to
faithfully
patch.
Without
actually,
you
know,
analyzing
the
text
that
will
be
evaluated
or
that
will
be
inside
the
width
was
when
when,
when,
as
code
declaration
conflicted
with
with
the
binding,
that
is
on
the
proxy
of
the
object
context
itself
for
that
with
closure.
B
B
A
B
C
A
I
mean
obviously
anything
you
can
do
with
the
width.
You
can
do
by
a
rewrite.
You
know
the
tyrrhene
universality
is
basically
by
rewrite.
You
can
do
anything
the
you
still
don't
just
just
checking
with
the
current
ACMA
script.
You
still
don't
know
of
any
way
to
do
this
with
without
rewriting
and
without
a
with
that.
It's
a
choice
between
one
or
the
other,
correct
I.
Think.
A
B
To
control
access
to
the
the
bindings
that
you
have
as
a
global
references
yeah,
and
if,
if
you
have
a
generic
way
to
control
that
for
a
solution
process-
and
you
don't
necessarily
have
to
create
a
global
object
as
it
is
today-
is
specified
in
the
in
262
as
a
global
object
and
in
general,
you
can
just
use
the
hook
to
do.
The
resolution
and
now
having
to
have
a
real
global
object,
be
created.
Okay,.
A
B
A
The
it'll
I
mean
it'll,
be
interesting
to
talk
dental
matters
and
see
what
they
think,
but
from
the
preview
from
previous
history
of
all
of
this
effort,
it
was
pretty
much
the
other
way
around.
Your
any
proposal
back
when
Dave
Herman
was
involved,
was
that,
rather
than
was
that
you
could
provide
a
essentially
a
proxy
Handler
and
then
it
would
create
essentially
the
equivalent
of
the
proxy
as
a
global
object,
meaning
that
the
variable
references
would
Fault
on
to
the
handler.
A
Yes,
which
is
pretty
pretty
much
what
we're
doing
with
the
eight
magic
lines
yeah
and
the
feedback,
at
least
at
the
time
that
we
got
from
implementers,
is
that
you
know
they've
got
all
of
this
optimization
for
accessing
variables
on
a
global
object,
so
that,
first
of
all
they
wanted
to
be.
The
implementation
creates
the
global.
It's
not
that
you
can
pass
an
object
in
US
and
but
second
of
all,
they
did.
They
did
want
it
to
be
they
if
they
did
not
like
the
idea
of
providing
a
handler
there.
B
He
didn't
want
to
have
any
dynamics
in
the
resolution
of
those
bindings
and
I
feel
that
I
feel
that
the
proxy
added
that
plus
the
the
exotic
aspect
of
the
global
object,
was
going
to
be
loose
somehow
in
the
proxy
thing
and
and
and
I
feel
that
having
the
ability
to
control
the
initialization
of
the
binding
is
really
key
here,
because
if
what
you
need
is
just
to
find
out
word,
do
these
binding
points
to
or
something
like
that,
and
you
do
that
during
the
initialization.
The
first
time
that
you
have
to
resolve
that
binding.
B
A
You
know
where
I'm
counting
a
import
declaration
as
a
as
a
declaration
of
the
variable
cuz
any
use
occurrence
in
that
scope
refers
to
that
declaration
and
multiple
modules
can
share
the
same
global,
but
each
module
clearly
has
to
have
its
own
distinct
top-level
lexical
namespace,
and
this
is
reflected
in
the
spec
as
the
distinction
between
the
the
the
per
module
lexical
environment
per
module,
record,
lexical
environment
versus
the
shared
a
realm
record
global
environment.
So
are
we
talking
about
both
of
those
and
we
make
a
distinction
between
them?
Yeah.
B
A
And
I
think
the
the
hard
problem
we
were
trying
to
deal
with
was
the
top-level
lexical
environment.
Can
we
let
the
global
object?
Mr.
okay,
we
should
have
kept
the
global
object.
Let's
put,
let's
put
the
global
object
in
the
global
environment
aside:
okay,
and
just
just
do
with
the
top-level
lexical
environment
50
wise
bindings
between
modules,
okay,.
B
Yeah
that
sounds
right:
okay,
okay,
so
we
we
have
such
capability.
Then,
when
you
are
evaluating
a
module,
you
have
the
level
of
control
of
saying
when
they
binding
this
audit
to
this
environment
record
and
the
name
might
be
different.
Now
the
module
environment
record
ones
that
they
they
binding
is
out
of
there
go
through
this
process
of
resolving
that,
and
this
process
will
be
able
to
allocate
something
different
there.
B
That
could
be
a
proxy
of
the
thing
that
you're
importing
and
this
proxy
can
add
the
proper
membrane
mechanist
to
attenuate
whatever
you
are
important,
so
you
don't
need
an
attenuated
attenuating
module
in
between.
You
can
just
simply
resolve
to
the
module,
evaluate
the
two
separate
modules
and
the
one
that
is
importing
from
the
one
that
might
have
issues
you
just
simply
use
the
hooks
to
control
access
to
those
things
and
create
a
separation
between
the
two
of
them.
Okay,.
A
A
We
want
to
interpose
a
membrane
between
the
two
so
that
what
module
a
sees
is
not
the
current
value
of
x
from
module
B,
but
a
membrane
proxy
for
the
current
value
of
x,
from
module
B
and
it's
gotten,
but
it
still
has
to
stay
live.
So
the
module
B
changes,
the
value
of
x,
then
module
a
sees.
A
still
sees
a
membrane
proxy
for
the
new
value
of
x.
A
A
B
A
Very
glad
to
have
identified
that
as
a
goal.
That
seems
like
a
very,
very
wonderful
goal.
That's
needed
for
us
to
identify-
and
this
is
this-
is
independent
of
whether
we're
using
multiple
realms
or
whether
we'll
all
all
inner
realm.
We
need
to
be
able
to
impose
membranes
and
being
able
to
impose
membranes
at
the
you
know,
to
cut
cut
excess
grass
and
being
able
to
pose
and
to
interpose
a
membrane
within
the
muddy
import.
Graph,
I
think
is
a
very
important
thing
to
have
identified.
Okay.
B
I
think
those
are
three
distinct
problems
that
we
need
solutions
for,
and
we
might
have
in
the
case
of
the
inform
at
we
might
have
solutions
already,
then
give
you
some
of
that.
Obviously
we
want
a
solution
that
give
you
a
lot
more
control
over
the
resolution
aspect
of
it,
while
the
evaluation
and
parsing.
We
have
nothing,
but
we
are
proposing
something
like
the
personal
type
of
the
static
module
record
and
then
from
there
getting
to
the
linkage
and
evaluation
which
we
are
looking
into
it.
Okay,.
B
B
A
Okay,
the
you
put
in
category
number
one
import
maps
and
to
put
in
category
number
two
you
included
linkage
and
evaluation
and
you
included
a
category
three
controlling
the
bindings
of
imports.
So
those
to
me
are
all
one
category
it
all
has
to
do
with
when
module
a
imports
says
it
wants
to
import
X
from
specifier
string
B.
What
does
it
get
and
and
then
the
the
other
half
of
number
one
was
resolution?
How
do
you
go
from
a
specifier
string
to
a
source
text
out
in
the
external
world?
A
That's
reached
by
some
kind
of
I/o
number
two
you've
had
parsing,
which
is
how
you
go
from
that
source
text
into
a
static
modulo
record,
so
I
think
that
I
think
that
the
the
the
the
most
important
lesson
that
I've
come
to
over
these
last
six
months.
We're
all
aggressing
with
this
over
these
meetings
was
the
lesson
that
became
clear
to
me
from
interacting
with
meta,
masks
and
embedded,
but
also
this
comes
out
with
the
you
know.
A
The
McGurk
module
system
that
that,
through
the
rewrite,
which
is
that
there's
one
set
of
issues
to
go
from
external
source
text
to
static
module
records,
and
that's
that
that's
a
that's
conceptually
an
earlier
phase
and
in
the
embedded
context
on,
is
actually
often
strictly
an
earlier
phase.
A
build
time
phase
and
then
there's
going
from
a
set
of
static
module
records
to
where
each
module
record
is
itself
completely.
A
A
A
You
know
that
it's
it's
the
key
step
that
made
it
possible
to
identify
what
is
in
common
between
what
we
need
for
general.
You
know
web
use
and
general
server
use,
etc.
On
a
general
blockchain
use,
of
course,
for
us
and
what's
needed
for
embedded
to
have
a
common
set
of
mechanism,
a
common
core
there
that
fit
with
all
of
us.
It's
this.
It's
the
stage
separation
of
those
two
things
that
were
central.
A
B
B
I'll
go
and
parse.
That
thing
for
you
and
I
will
get
it
ready
to
be
evaluated
in
the
context
of
this
round
that
the
the
what
the
evaluator
is
on
you.
So
the
identity
of
the
things
created
by
this
module,
one
evaluated,
are
going
to
be
associated
to
this
realm
and
such
and
at
that
point,
as
I
parse,
the
module
the
source
of
the
module
I
will
be
able
to
go
and
decide.
B
You
get
to
that
point
where
we're
talking
about
untrusted
code
here
and
and
so
I'm
evaluating
the
source
of
jQuery
that
imports,
sisal
and
I
have
identified
a
way
to
resolve
that,
but
the
Mojo
might
be
coming
from
a
already
existing
in
memory
in
terms
of
that
in
a
different
role
or
I
wanted
to
do
in
the
same
realm
by
finding
the
source
and
parsing
the
source
and
getting
the
interns
ready
for
the
linkage
and
such
either
way.
It's
fine.
B
But
up
to
this
point,
it's
all
about
finding
things
that
might
be
already
namespace
objects
that
you
have
in
memory
or
brand
new
source
that
you
need
to
parse
and
get
ready
for
evaluation.
I.
Think
that
aligns
very
well
with
what
it
is
in
the
API
today
in
the
compartment
API
State
I
believe
so
they.
A
Do
so
the
compartment
API
today
the
there's
that
there's
this
thing
in
it
that
I
purposely
I
was
purposely
ambiguous
about
a
point
in
my
presentation
with
regard
to
the
import
map
and
what
I
presented,
which
is
I
used.
The
I
said
the
import
map
in
the
API
is
a
mapping
from
child
specifier,
name
to
either
parent
specifier
name
your
module
namespace
object,
and
by
using
the
mapping
notation,
you
write
the
right
arrow
I.
A
Did
not
pin
down
whether
I
was
talking
about
a
function
providing
the
mapping
or
I
was
talking
about
a
data
structure
providing
than
that
thing
and
the
what
I
have
in
mind
there
is
that
that
there's,
two
separate
abstractions
that
are
needed
to
cover
the
whole.
You
know
the
whole
problem
which
corresponds
to
these
two
phases,
which
is
what
I've
been
lately
calling
the
loader
versus
the
compartment
and
the
loader
is
so.
A
So
the
the
comparison
that
I
made
in
the
talk
that
was
trying
to
set
things
up
to
talk
about
this
explicitly
was
when
I
was
making
the
comparison
with
virtual
memory
and
mm
use
and
that
mm
use
might
just
map
to
an
existing
page,
in
which
case
they're
just
doing
mapping.
There's
no
traps
involved,
or
they
they
might.
A
The
virtual
address
might
not
correspond
to
any
existing
physical
page,
in
which
case
some
other
mechanism
has
to
be
woken
up
by
the
trap
and
go
fetch
the
fetcher
or
create
the
physical
page
from
somewhere.
Provided
you
know
that
only
once
the
physical
page
is
provided,
can
the
MMU
then
proceed
to
map
the
virtual
address
to
the
now
existing
physical
page?
So
I
see
the
loader
as
the
thing.
A
That's
basically
handling
these
naming
faults
where
you're
naming
something
that
does
not
yet
correspond
to
a
a
module
static
record
that
you
already
have
and
when
it
brings
up
one
in
it
does
the
person,
because
the
module
static
record
is
already
post
parsing.
This
is
why
I'm
always
going
to
you
know
to
step
in
when
you
say,
parsing
and
evaluation,
because
they're
completely
distinct
phases.
Parsing
is
isolated
in
per
module,
linkage
and
evaluation,
and
all
that
is
all
between
modules.
A
The
other
thing
that
is
important
about
the
module
static
record
if
we
reify
it,
which
so
far
the
compartment
has
not
needed
to
reify
it,
that
the
loader
might
provide
a
view
of
the
reified.
One
is
being
able
to
say
about
a
module
static
record
to
just
ask
explicitly
about
the
static
record.
What
are
the
names
that
it
imports
and
what
are
the
names
that
it
exports?
I?
Think
that
that's
already
part
of
the
static
modular
record
data
structure
and
I
think
it
was
already
part
of
the
API
that
you
showed
this
for
reifying.
A
Think
I
think
free
for
purposes
of
customizing
loading.
It
makes
perfect
sense
to
expose
those
names
derived
from
parsing
so
that
an
algorithm
user
reading
algorithm
can
walk
over
those
names
and
trigger
further
faulting.
Based
on
me
on
the
names
that
it's
provided.
They're
all
going
for
module
static
record
to
module
static
record.
A
But
the
and
the
reason
for
plugging
these
things
together
is
it
says
that,
even
though
there
are
these
two
conceptually
separate
phases,
it
doesn't
mean
that
that
that
all
modules
have
to
be
loaded
before
any
modules
get
evaluated.
They're
plugged
together
in
this
faulting
manner
and
they're
separating
to
two
separate
abstractions.
But
by
doing
that
in
a
typical
embedded
configuration
there
doesn't
need
to
be
any
runtime
loader
whatsoever.
So
you
don't
need
a
typical
embedded
configuration.
A
The
thing
that
shipped
in
the
device
has
no
ability
to
even
par
Strava
script,
because
if
all
source
text
exists
up
front,
you
don't
need
to
be
able
to
parse
a
java
script
in
the
device.
But
you
still
need
to
be
able
to
create
compartments
and
separate
instantiation
linkage
and
all
that
in
order
to
do
least
Authority
linkage
and
separation
of
authority.
B
If
we
get
to
provide
a
level
of
control
during
the
evaluation
of
the
body
of
the
module,
so
that
sort
of
they
explained
why
I
was
and
I
wasn't
really
paying
too
much
attention
to
the
fact
that
in
some
cases
you
still
want
to
have
a
complete
separate
version
of
it,
what
it
does
and
the
same
ROM
or
different
realm
or
same
compartment
or
different
compartments.
I,
don't
think
you
you
ever!
You
will
ever
be
able
to
do
that
in
or
or
it's
useful
to
do,
that
in
separate
compartments
from
the
same
round.
B
A
B
B
A
The
brief
ID
version
will
be
an
object
from
some
realm,
but
the
instance,
but
the
the
process
of
instantiating
it,
the
the
module,
the
informational
information
contained
in
a
module
static
record
has
nothing
to
do
with
what
realm
it's
reified
int,
so
the
instant
when
you
make
module
instances
of
it.
Those
instances
could
be
instances
in
a
completely
unrelated
route
right.
B
A
C
B
And
that
process
of
deciding
that
it's
a
it's
is
a
very
interesting
process,
because
I
I,
suspect
I
was
on
the
assumption
that
well,
if
you
have
these
reified
object
that
belongs
to
a
ROM,
you
can
just
simply
assume
that
they
refi
top
gate,
carries
certain
information
about
the
realm.
That,
once
you
create
an
intense
out
of
that
static
record
in
my
carry,
is
the
same
identity
that
their
realm
associated
to
these
rarefied
object.
B
But
if,
if,
if
possible,
it
might
be
interesting
to
explore
the
ability
to
do
it
in
a
complete
different
wrong.
I
haven't
think
about
that
kind
of
API
and
that
kind
of
API
doesn't
exist
in
in
the
language
to
the
age,
because
we
don't
have
many
things
about
separate,
realms
and
such,
but
it
will
be
interesting.
I
was
on
the
assumption
that
just
the
identity
of
the
of
the
reified
update
is
sufficient
to
say
in
tenses
associated
to
this
started
record
belong
to
that
round.
A
But
but
you
still
have
to
be
able
to
take
the
same
module,
static
record
and
multiple--
instantiated
to
instantiate
it
in
different
compartments.
So,
for
example,
if
the
module
instance
represents
a
communications
channel
among
those
who
import
it,
you
can
create
isolation
by
separately,
instantiating
it
in
separate,
isolated
sub-graphs
by
represented
by
distinct
compartments
with
isolated
import
graphs.
So
I.
A
B
That's
why
last
week,
I
was
talking
about
parsing
and
the
indentation
process,
almost
as
the
same
thing,
or
it
known
as
the
sadly
a
distinct
thing,
because
I
was
on
the
assumption
that
when
you
parse
your
person
with
a
particular
API
that
belongs
to
a
realm,
and
that
carries
a
certain
way
into
the
process.
That
the
intents
of
this
thing
that
you're
parsing
will
come
out
of
that
round.
A
We
don't
have,
you
know
a
rich
enough
set
of
new
value
types,
but
there's
nothing
about
it,
semantically
that
conveys
anything
other.
You
know,
there's
nothing
about
it.
That
is
realm
specific
and
in
fact,
if
you're
in
a
multiple
realm
environment,
then
you
don't
want
to
even
pay
the
overhead
of
person
at
multiple
times,
because
the
parsing
of
it
is
completely
context
independent,
it's
just
according
to
the
specification
of
the
programming
language.
So
if
the
realms
are
running
the
same
programming
like
you'd
like
to
just
purse,
it
once.
B
Hey
yeah
the
the
fact
that
you
can
place
a
membrane
between
the
these
different
modules
are
imported.
Untrusted
module.
Give
you
a
lot
more
control
of
what
these
untrusted
module
can
do
and
in
the
case
of
membranes,
for
example,
there
is
some
some
level
of
some
semantics
that
you
can
add
to
the
membrane
what
whether
or
not
the
objects
that
these
membranes
are
seen
are
frozen
or
not.
That's
an
example
of
it,
but
the
fact
that
I
was
assuming
that
it
is
possible
to
share
that
intense.
A
I
think
you
were,
let's
take
a
concrete
example.
Let's
take
a
concrete
example
from
multiple:
let's
have
a
module
that
simply
exports
a
function
named
April
and
it
has
internally
a
top-level
variable
that
it
does
not
export
I'll
called
count,
and
what
Ankur
does
is
it
just
says:
it's
just
a
function
that
says
return
plus
plus
count.
B
B
B
You
don't
want
to
have
the
side
channels
associated
to
sharing
the
same
the
same
in
terms
of
the
module
with
multiple
importers,
but
the
flip
side
of
it
is
that
sometimes
you
do
want
that
level
of
sharing,
even
though
and
they
and
the
api's
that
we
that
we
need
to
provide
shoe
support
both
of
that.
Yes,
good
good,
we're
great,
and
this
is
all
the
example
that
you
were
saying
you
you
saying
you-
you
have
Carol.
A
Carol
and
Dave
are
two
module
instances
that
should
both
see
a
shared
count.
They
should
both
see
the
count
value
that
they're,
seeing
is
the
count.
Value
is
incremented
by
either
of
them,
and
likewise
Alice
and
Bob
are
two
different
module
instances
that
are
isolated
from
Carol
and
Dave,
but
they're
using
their
their
they've
imported.
What
is
the
same?
Module
static
record
was
conceptually
the
same
static
module
but
they're
getting
a
different
instance
of
it
so
that
they
see
a
shared
count
according
to
our
either
examining.
B
A
A
A
A
B
B
A
B
A
A
For
example,
in
your
in
your
evaluator
API
that
you
presented
last
time,
you
had
a
operation
for
going
from
module
source
text
to
a
you
know,
to
a
module,
something
I'm,
not
sure,
a
module
static
record,
a
module
instance
with
new
distinguishing.
But
but
yours
you
were
able
to
go
from
source
text
to
something
that
you
could
evaluate.
B
B
So
if
I
do
the
Expando
on
Carol
I
mean
I'm
going
to
use
it
a
side
channel
here
to
simply
use
that
thing
to
our
things
and
be
able
to
share
with
everyone
of
who
has
access
to
the
increment,
that's
right,
and
so,
if
I
run
this
thing
again,
I
should
be
able
to
see
that
the
expander
does
work
on
Kara
on
Dave,
but
do
not
work
on
alleys
involved
because
they
are
in
a
different
pocket.
Yes-
and
this
is
what
the
membranes
protection
provides
on
top
of
days,.
B
Count
is
going
to
yeah
because
it's
part
of
the
logic
of
the
module.
Yes,
in
that
case,
you
have
to
say
well,
I
want
a
different
version
of
these
right.
I
have
the
first
version
in
there
they
okay
static,
a
module
record,
go
on
reuse,
that
in
a
new
realm
or
in
the
same
realm,
somehow
I
still
fall,
see
I'm
still
fuzzy
about
the
same
ROM.
The
same
module
but
I
feel
that
that
will
be
a
little
bit
tricky
because.
B
A
B
Have
to
resolve
those
two
right:
yeah
yeah
create
that's
right.
It's
two
one
I'm
use
the
static
for
those
and
there's
a
new
module
graph.
That's
right!
So
in
that
case
yeah,
it's
fine
to
do
it
in
this.
In
the
same
realm,
not
to
build
the
entire
thing
again,
but
the
same
realm
where
it's
fine,
okay,.
A
B
A
B
Okay,
yeah
so
yeah,
so
this
is
sort
of
an
example
of
what
we
have
right
now
we're
each
of
the
buckets
our
top
level
folders
on
sores.
Here
each
of
these
buckets
they
have
a
different
global.
They
have
a
membrane
in
between
then
that
controls
what
they're
trying
to
do
with
respect
to
the
things
that
they
are
importing
and-
and
this
membrane
has
the
ability
to
define
distortions
between
the
application
and
what
these
different
pockets
of
code
will
see,
and
obviously
it's
going
through
translation.
A
So
you
just
make
sure
that
we're
also
sounds
like
there's
there's
a
whole
lot
we're
in
agreement
on.
We
you've
been
focusing
on
the
membrane
interposition
between
modules
that
I
have
not
been,
and
we
both
agree
that
we
need
to
support
that
I've
been
focusing
on
the
multiple
instantiation
and
you
have
not,
but
you
both
agree.
We
both
need
to
support
that
we've
been
implementing
a
shim
using
the
eight
magic
lines
of
code.
B
Yeah
I
think
we're
agreeing
that
one
side
note
is
a
the
reason
why
we
do
not
focus
on
until
now
or
or
we
haven't
really
have.
They
need
to
focus
on.
The
multiple
intentions
of
counter
is
because
you
can
achieve
the
same
today,
multiple
ways
by
providing
an
import
Maps
that
result
to
a
different
module
and
let
the
server
who
provide
who
serve
the
file,
give
you
the
same
file,
which
will
require
free,
parsing
and
such,
but
you
could
achieve
that
today.
It's
not
the
overhead
is
there,
but
it's
achievable.
A
A
Okay,
so,
first
of
all,
let
me
let
me
check
whether
we're
also
greening
on
a
conclusion
that
I'm
drawing
from
this
conversation,
which
is
the
the
separation
of
loader
versus
compartment
as
representing
these
two
phases,
not
that
their
chronological
phases
they
can
be
one
can
trigger
the
other.
But
still
there
are
two
conceptually
separate
phases
that
that
separation
has
survived.
To
my
mind,
this
entire
discussion
still
a
great
separation,
and
it's
one
that
we
should
be
able
to
agree
on
I.
A
Loader
is
the
thing
that
goes
from
a
demand
for
a
name
into
a
a
module,
static,
record
and
possible,
in
fact
likely.
The
coexistence
of
other
related
modules
static
records
according
to,
given
that
the
user
can
look
at
the
module,
static
record
figure
out
what
names
and
imports,
and
then
you
go
through
a
name.
A
You
know
it's
part
of
the
loading
behavior.
You
know
going
through
some
algorithm,
the
user
provides
for
which
will
obviously
provide
some
defaults
so
that
they
can
go
from
external
source
text
reachable
through
some
IO
means
into
a
set
of
loaded
module,
static
records
associated
with
specifier
names
such
that
that
mapping
can
be
provided
to
the
compartment
API
to
satisfy
the
compartment.
Api's
demand
for
module
static,
corresponding
to
names.
B
Yeah
yeah,
yes,
I,
think.
B
B
Like
what
this
is,
this
is
really
the
API
that
Dave
was
referencing
as
the
module
reflection
API,
which
allows
you
to
okay,
because
at
some
point
this
API
might
also
allow
you
to
simply
create
an
artificial
module,
some
sorts
in
modules,
some
sort.
That's
right!
It's
really
just
just
trying
to
give
you
the
power
to
do
the
saying
that
normally
the
browser
will
do
for
you,
yes,
and
he
called
a
module
reflection
idea.
Okay,.
A
B
Really
the
loader
you're
doing
it
in
use
a
la
mode
you're,
the
one
in
control
you're
going
to
do
the
fetch
you're
going
to
do
the
parts
by
calling
an
API
to
parse
and
you're
going
to
do
something
with
that
thing.
So
you're
not
really
you're,
not
really
providing
an
API.
That
magically
goes
and
do
the
I/o
you're
telling
the
user
go
and
do
the
thing
that
you
need,
whether
that's
I/o
or
not,
and
give
me
the
things
that
I
need
in
order
to
carry
on.
B
A
B
So,
let's
keep
going
on
that
on
that,
because
I
I
sometimes
lose
track
of
certain
things
along
the
way.
So
when,
when
we're
talking
about
evaluating
a
module-
and
we
have
the
level
of
control
at
the
evaluator
compartment
level,
DiMaggio
we're
going
to
have
a
API
that
that
solved
the
problem
that
we
have
been
talking
today,
initial
problem
of
controlling
the
bindings
for
that
module.
B
B
Okay,
so
we
have
a
compartment
that
has
the
hooks
any
module
that
this
compartment
has
to
go
on,
Everglade,
which
is
part
of
the
process
of
going
through
the
module
graph
and
evaluating
all
the
missing
pieces,
because
there
might
be
some
event
that
are
irregular
in
another
compartment
or
in
another
realm.
I.
Get
that
point,
there's
only
the
things
that
we're
going
to
evaluate,
because
those
are
the
things
that
we
really
want
to
have
the
level
of
control.
B
There
I
often
struggle
with
the
concept
of
when
this
compartment
is
going
to
evaluate
that
or
the
code.
How
we'll
have
a
hook
that
will
have
enough
information
passed
to
the
hook
that
allows
to
make
decisions
about
what
what
kind
of
membranes
and
what
kind
of
protection
we're
going
to
give
to
that
particular
module.
That
is
being
evaluated
and
I
sort
of
get
that,
but
once
it
comes
to
multi,
multi
realms
or
you
have
multiple
evaluators
in
in
the
two
different
realms
twirlers
in
two
different
wrong
and
and
you're
sort
of
sharing
some
pieces
away.
B
Who
is
in
control
of
the
aberration
of
the
point?
The
fact
that
evaluator
in
bucket
a
is
using
a
reference
to
a
static
module
record
from
bucket
B
we're
going
to
create
an
instance
of
it
in
bucket,
be
once
we
need
it,
and
we
define
that
linkage,
but
his
pocket
a
the
one
going
through
the
module
grapha
evaluating
the
pieces
of
it
when
he
gets
to
the
module
that
is
coming
from
pocket
B.
Who
is
in
control?
Is
it
the
evaluator
in
bucket
B,
or
is
it
the
evaluator
in
pocket?
Eight,
okay,.
A
So
here
so
I'll
talk
to
you
what
I
have
in
mind
with
regard
to
compartments
within
a
ROM
and
I,
believe
everything
I'm
going
to
say,
should
apply
across
realms.
So
let
me
try
it
out.
I
have
not
tried
this
before,
so
the
idea
is
that
if
you
have
linked
together
compartments,
it
can
be
even
the
you
know:
the
compartments,
a
and
B
that
we
were
just
talking
about
with
yeah.
A
So
the
so
the
the
clearest
situation
is
there's
yet
another
compartment
that
set
up
the
relationship
between
a
and
B
and
I
think
that
works,
even
if
a
and
B
are
across
realms,
because,
if
they're
across
realms,
there
still
needs
to
be
some
code
that
knew
about
both
realms
in
order
to
set
up
a
relationship.
So
let's
call
that
start
compartment.
So
the
start
compartment
is
in
the
same
realm,
let's
say
as
compartment
ND
and
the
starting
part.
A
So
the
start
compartment
creates
compartment
a
in
its
own
realm
and
maybe
the
start
compartment
uses
the
realm
API
to
create
a
separate
realm
and
then
uses
the
compartment
API
of
that
separate
realm
to
create
compartment
day
and
now
it
causes
a
module
to
get
loaded
into
compartment
B
and
it
gets
the
module
name.
Space
object
from
the
loaded
module
instance
and
then
it
created.
Then
it
going
back
then.
So
it
does
that
first
once
a
and
then
when
it
creates
an.
A
All
right,
so
it
start
compartment
first
creates
a
realm
for
compartment
B.
Then
it
creates
within
that
realm
that
creates
compartment,
be
using
that
realms
compartment,
constructor
yeah,
and
then
it,
however,
it
does
it
loads.
It
causes
a
module
instance
to
be
instantiated
in
compartment
B,
so
that
module
instance
is
clearly
of
that
other
realm,
but
its
name.
Space
object
is
a
genuine
module
name.
A
Space
object,
I'm,
going
to
ignore
for
a
moment
all
the
desires
we
have
that
we
agree
on
for
met
for
remembering
these
things
I'm
just
going
to
do
water,
yes,
so
then
what
it
does
is
when
it
creates
so
so
the
start
compartment
now
has
a
hold
of
that
name.
Space
object
now.
The
start
compartment
creates
compartment
a
in
its
own
realm
and
it
provides
in
the
module
map
for
compartment
a
a
mapping
from
the
specifier
string
foo
to
the
module
name,
space
object.
It
had
obtained
from
compartment
B.
B
No
up
to
this
point
everything
is
clear.
Okay,
the
my
problem
was:
if
I
want
to
control.
I
know
you're
not
talking
about
the
membranes,
but
that's
where
things
get
a
little
bit
more
tricky
for
me,
because
in
order
for
four
or
the
module
in
compartment
a
to
create
a
binding
to
something
from
compartment,
B.
A
Yeah,
it
was
a
terminology
issue
and
the
reason
I
think
it's
tremendous
amount
of
these
terminology
issues.
The
thing
that
took
me
months
longer
to
understand
what
moddable
was
doing,
but
it
should
have
is
the
fact
that
the
spec
uses
just
the
abstraction
of
module
record
both
for
the
static
information
and
for
the
instance,
and
you
just
made
it
impossible
to
separate
concepts
so
so
in
the
multiple
system
at
v--.
A
If
you
provide
a
name
to
name
mapping
in
the
compartment
API
when
you're
creating
a
new
compartment,
then
you're,
then
everything
that
gets
instantiated
and
gets
instantiated
in
the
new
compartment.
There's
no
cross
compartment
linkage
of
instances,
if
you
only
provide
name
to
name
and
mappings,
because
the
name
is
only
looking
up
when
you
provide
a
name
to
name
mapping.
A
The
only
things
you're
looking
up
from
the
name
are
module,
is
static
records
and
then
that
module
static
record
will
be
freshly
instantiated
in
the
new
compartment
independent
of
whether
it
has
been
instantiated
in
other
compartments.
If
you
want
not
to
separately
instantiate
it,
but
you
want
to
do
a
cross
compartment
linkage,
then
you
provide
the
module
name.
Space
object
and
the
reason
we
provide
the
module
name.
B
A
A
Way,
the
idea
is
that
the
star
compartment
can,
can
you
obtain
these
module
name,
space
objects
and
then
the
start
compartment
can
use
that
to
talk
about
module
instances.
Now
this
is
indirect.
The
other
more
direct
option
that
would
be
more
cycle
friendly
is
to
introduce
into
the
API
and
explicit
reification
of
a
module
instance.
The
only
reason
we
were
using
module
name
space
objects
is
to
avoid
that
reification
yeah.
B
B
That
allow
me
to
decide
the
resolution
of
the
binding
during
the
evaluation
of
the
module.
I
need
to
know
what
this
module
is
about.
I
might
have
provide
only
the
static
module
record
as
part
of
the
map
and
therefore,
when
the
Incans
comes
up,
I
will
not
be
able
to
tag
that
back
to
the
module
record,
because
it's
the
internals
doing
the
process
of
this
is
a
static
model.
B
Record
I
need
to
create
an
instance
of
it
and
I
need
to
give
it
back
to
you
because
I'm
about
to
evaluate
the
cold
air
and
you
need
to
resolve
binding
food.
So
the
mapping
there
for
me
was
lost
in
the
sea
like
how
can
I
know
what
to
do?
Okay,
that's
why
I
was
asking
what
kind
of
API
can
we
have
that?
Allow
me
to
identify
the
module
in
such
a
way
that
I
can
have
a
generic
hook.
That
I
will
be
able
to
provide
a
ride.
Membrane
implementation,
that's
option
number
one!
B
We
could
try
to
solve
that
problem.
Option
number
two
is
ignored
the
hook,
as
they
add
the
component
at
the
compartment
level,
and
at
the
hook
these
refined
new
object
represent
a
module,
intends
that
hasn't
been
intensive
a
little
yet
so,
just
like
you
do
parsing
by
having
a
source,
and
you
do
the
parsing
on
it.
You
could
also
do
the
same
by
saying.
I
have
this
first
static
module
record
I
want
to
create
a
thing
out
of
it,
and
I
want
to
provide
a
hooks
that
I
want.
B
So
when
this
thing
is
evaluated,
I
can
do
the
resolutions
of
the
pieces
for
that
thing.
I
already
know
who
that
who
that
is,
because
it's
created
off
the
module
record
and
I
feel
that
that
one
is
a
little
bit
more
more
flexible
for
me,
because
then
in
a
module
graph,
you
would
be
creating
these
things
and
you
will
be
able
to
control
what
each
of
these
things
are
going
to
do
in
terms
of
I/o.
A
So
that
all
sounds
plausible
to
me,
I
think
we
should
go
through
that
exercise.
The
idea
of
taking
these
internal
abstractions
and
turning
them
into
reified
abstractions
with
exposed
api's
I
find
that
attractive
and
then
the
the
the
simple
pattern
exposed
through
the
existing
compartment
api
could
just
be
a
convenience
on
top
of
that.
B
A
Yeah
next,
no
next
week
is
fine.
I
was
thinking
with
TC
53
who's
going
to
be
meeting
Tuesday
and
Wednesday,
which
obviously
we
will
be
discussing
a
lot
of
this
then
as
well
I'll
be
giving
again
an
extended
form
of
the
talk
that
I
gave
the
tc39
I'll
be
giving
that
TC
23.
Okay,
okay,
okay,
see
you
next
week,
bye,
okay,
bye.