►
From YouTube: SES-mtg: Oct7 title soon
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
A
C
A
All
right,
I
think
I
should
my
anyhow:
everybody
can
see
the
agenda
cool,
we
have
an
agenda
and
it
matches
what
our
minutes
will
be
all
right.
Let's
hope
that
this
works.
A
I
believe
everybody's
seeing
slide
compartments
and
node
underscore
modules.
Yes,
all
right.
This
is,
I
think,
where
I
lost
everyone.
So,
let's
proceed
to
some
definitions.
A
All
right
so
in
the
context
of
of
the
module
loading
compartment,
api
resolve
is
a
synchronous
function
that
takes
an
import
specifier
and
produces
the
corresponding
full,
an
import,
specifier
and
a
referrer
module
specifier
and
produces
the
corresponding
full
module.
Specifier,
it's
a
synchronous
function
and
it
is
different
for
the
web,
which
is
based
off
of
urls
and
and
a
dialect
of
an
interpretation
of
node.js
modules
where
every
package
has
a
unique
module
identifier
namespace
and
only
can
refer
to
things
in
that
package.
A
That
is
not
how
node
works,
but
it
is
a
valid
interpretation
that
fits
into
the
compartment
model
which
I'll
describe
a
module.
Specifier
is
the
string
referring
to
another
module.
These
appear
in
many
places
and
apis
they
come
in
multiple
flavors.
A
full
specifier,
isn't
a
valid
key
in
any
of
the
compartments
module
maps,
sometimes
called
a
cache
key.
A
Some
kind
of
times
called
a
memo
key,
whereas
a
partial
specifier
is
anything,
that's
not
a
full
specifier
and
these,
and
so
when
you
write
an
import
statement,
what
you
have
there
is
potentially
a
full
or
partial
specifier.
The
resolve
function
transforms
it
into
a
full
specifier
for
the
purposes
of
fetching
and
all
the
other
things
that
are
all
mechanisms
behind
loading,
module,
loading
and
executing
modules.
The
module
referrer
is
the
the
module
in
is
the
roof.
A
It
must
that
must
be
interpreted
in
the
context
of
its
referrer
and
in
the
context
of
the
resolve
function
of
the
compartment
it's
in,
and
there
are
some
details
I
won't
go
into
on
that,
but
it
affects
how
access
interprets
modules,
a
relative,
specifier
and
an
absolute
specifier
are
different
things
and
and
I'll
explain
how
they
are
orthogonal
on
the
next
slide.
A
But
a
relative
specifier
is
simply
a
node.js
convention
that
for
where,
where
the
path,
if
the
first
path
component
is
a
dot
or
dot
dot,
and
if
any
of
the
other
and
any
of
the
other
components
may
be
dot
or
dot
dot
that,
when
resolved
in
a
node.js
resolution,
get
converted
into
that
get
erased,
some
of
which
get
erased
and
an
absolute
specifier
is
non-relative
and
to
be
go
ahead.
A
B
D
Oh,
that's
actually
quite
complicated
and
resolve
a
module
specifier.
They
actually
blacklist
other
stuff.
A
C
Specifically,
leave
out
bear
specifier
here
for
terminology
reasons.
A
Yeah
yeah
there
are
num.
There
are
a
number
of
things
about
the
web
resolution,
but
I
I
think
the
big
takeaway
here
is
that
there
are
two
very
different
logical,
the
two
very
different
logical
name,
spaces
and
and
in
one
of
them
relative
and
in
each
of
them.
Relative
and
absolute
are
are
domain,
specific
terms
and
the
compartment
api
does
not
know
or
care
about
them.
B
A
Yeah,
by
coincidence,
I
would
argue
that
bear
specifiers
are
that
they
are
meaningful
in
both
and
they
happen
to
mean
the
same
thing,
but
it
is
not.
What
I'm
proposing
is
that
it
is
not
the
compartment
api
that
is
imposing
this
convention,
that
that
is
an
effect
of
coincidence
between
the
implement
between
the
implied,
resolve
and
and
locate
functions
of
those
spaces
and
the
compartment
api
does
not
deal
in
those
details.
C
Okay,
maybe
we
can
find
a
time
to
discuss
that
further.
I
don't
want
to
take
things
off
track
now
for
sure.
A
Yeah
to
continue,
I
think
I
may
have
I'll
come
back
to
this,
the
low
yeah
I
there
I
have
more
to
say
on
that
topic,
but
I
want
to
get
through
the
glossary
first,
the
so
specifically
about
behavior
of
compartments
a
load
hook.
I
define
as
a
function
that
locates
meaning
taking
locates
retrieves,
parses
and
analyzes
the
dependencies
of
a
particular
module
and
produces
the
module
record
for
a
particular
module
specifier.
A
This
is
a
lot
of
work,
so
let
me
get
it
and
let
me
drill
into
this
particular
this
is,
and
this
is
implementation
specific.
The
compartment
api
exposes
a
load
hook
and
it's
the
responsibility
of
the
load
hook
to
implement,
locate,
retrieve
parse
analyze
and
those
are
not
terms
of
our
of
the
compartment
api
itself
to
locate
and
it's
an
asynchronous
function.
All
of
these
phases
are
may
be
asynchronous.
A
As
far
as
the
compartment
api
is
concerned,
the
locate
method,
the
locate
method,
is
responsible
for,
in
the
context
of
a
particular
compartment,
taking
a
module
specifier
and
finding
the
corresponding
location
of
the
text
of
that
module,
and
that
may
be
on
a
file
system,
and
maybe
it
might
be
a
url,
and
that
is
all
implementation
specific.
A
So
the
backing
store
for
modules
is
not
a
concern
of
the
compartment
api.
It
is
a
concern
that
is
delegated
to
the
constructor
of
a
compartment
so
that
they
can
pass
that
behavior
in
as
a
load
hook,
and
so
locating
can
be
just
a
synchronous,
logical
operation,
depending
on
what
your
backing
store
is.
If
your
backing
store
is
a
zip
file,
that's
entirely
in
memory.
A
Locate
can
be
synchronous,
but
it
is
free
to
be
asynchronous,
which
is
important
because
the
web
and
node
have
behaviors
for
following
redirects
and
canonicalizing
the
locations
that
that
are
that
are
captured
underneath
this,
that
this
external
concern
and
the
analysis
of
dependencies
is
a
utility
that
we
provide
because
which
I'll
explain
later
the
load
function
is.
Loading
in
general
is
recursively,
inducing
the
load
hook
for
a
module
and
its
transitive
dependencies
growing
out
the
the
working
set.
A
If
you
will
building
building
out
the
internal
maps
of
the
compartment
from
module
specifier
to
module
record
for
a
particular
entry
point
and
its
transitive
dependencies
go
ahead.
C
Well,
you,
you
feels,
like
you've
glossed
over
some
stuff
there.
First
of
all,
though,
when
he
says
load
hook,
hook
is
generally
thought
of
as
a
an
application
provided
function
to
to
insert
into
some
kind
of
infrastructure,
provided
greater
functionality.
C
True
and
that's
kind
of
not
what's
going
on
here
in
the
sense
that
you
have
you're
going
to
have
different
different
ones
of
these.
For
say
you
know,
you
know
different
kinds
of
compartments
or
bundling
or
packaging
things
you're
loading
over
the
web
or
loading
from
a
file
or
from
a
zip
file
whatever
so
there's
going
to
be
variation
there,
yes,
but
it's
it's
provided
by
the
implementation
of
whatever
you're
using.
So
it's
kind
of
weird
how
to
hook.
B
It's
provided
when
you
create
a
compartment.
You
provide
a
load
hook
as
a
as
a
optional
parameter
to
the
compartment,
so
it
is
the
case
user
javascript.
C
So
so
the
the
roles
of
the
sort
of
the
different
different
actors
in
the
play
was
not
clear
and
then
the
other
thing
was
you
talk
about
the
map
of
module
records.
That's
the
map
from
the
the.
C
Module
what
you
call
the
module
specifier
and
but
you
you
have
these
various
different
species
of
specifiers
that
you
you
laid
out
on
the
prior
slide.
This
map
maps
from
any
of
those
or
just
from
the
absolute
specifier,
the
full
specimen.
B
Okay,
so
that
first
definition
of
load
hook,
the
the
risk
ends
with
for
a
module
specifier
that
could
accurately
be
stated
as
for
a
full
module,
specifier.
A
C
Is
and
is
the
is,
the
is
the
translation
from
a
a
something
that
is
not
a
full
specifier
to
a
full
specifier
related
to
the
implementation
of
the
load
hook
in
any
way.
A
No,
it's
the
resolve
hook.
Result,
that's
that's
the
operation
yeah
the
resolve
hook
is
is
consistent
across
the
logical
domain
of
module,
specifiers
and
so,
for
example,
you
would
only
need
one
such
function
for
any
compartment
is
that
you
would
use
a
single
function
for
any
compartment.
That's
using
nodes
logic
for
resolution,
for
example,
and
a
different
one
for
every
anything,
that's
using
web
resolution
so
conceivably.
This
is
a
world
with
possibly
a
world
with
only
two
resolve
hooks.
B
Okay,
I
see
peter
just
joined
us.
I
think
that
backing
up
one
slide
to
recapitulate,
the
glossary.
B
B
B
For
being
late,
I
thought
I
would
join
and
listen
in
just
to
kind
of
catch
up
on
things.
Awesome.
A
Thank
you,
we're
very
glad
to
have
you
here
we're
going
to
bank
we've
only
done
one
slide
so
far,
I'm
going
to
recap
the
previous
one.
Let
me
see
if
I
can
yeah
that's
what
I
thought.
You
click
and
it
goes
forward.
It's
one
for
two
steps
back
so
so
begin.
A
So
this
is
a
presentation
about
where
we
stand
with,
with
the
compartment
api
and
all
of
the
other
cess
apis
and
where
we
need
to
go
in
order
to
reconcile
and
harden
and
write
the
specifications
for
these
and
then
maybe
converge.
Some
bring
bring
some
knowledge
together
from
all
of
the
implementations
and
and
stir
them
into
the
pot,
the
gl.
So
I'm
going
through
a
glossary
of
terms
that
was
is
markedly
absent.
A
Last
time
I
got
through
half
of
this
presentation,
so
in
order
for
the
rest
of
this,
to
make
sense
resolve
is
a
synchronous
function
that
takes
an
import,
specifier
and
and
a
referrer
specifier
to
produce
a
full
specifier
which
I
get
into,
and
the
resolve
function
is
a
hook
that
you
that
you
can
create
a
compartment
with
a
module,
a
dynamically
module
loading
compartment
api
that
that
layer
of
the
compartment
api
should
we
get
there
needs
it
would
need
the
the
constructor
to
pass
a
a
a
definition
of
the
resolve
function
there
are
potentially
there
are.
A
There
is
there.
It
is
an
open-ended,
an
open-ended
api,
but
in
practice
there
will
be
one
resolve
function
that
is
suitable
for
the
logical
definition
of
of
of
module,
red
specifier
resolution
in
node
modules
and
then
a
different
one
for
the
web,
and
and
because
we
have
this
hook,
we
may
have
the
ability
to
reconcile
those
worlds
under
a
single
roof
where
you
could
have
some
compartments
in
the
web
world
and
some
compartments
and
in
the
node
world,
and
they
would
be
able
to
interact
with
each
other.
A
module.
A
Specifier
is
a
string
that
refers
to
another
module.
Simply
it
comes
in
many
species.
A
full
specifier
is
a
valid
cache
key
or
memo
key
in
in
a
com
in
a
single
compartments.
That's
scoped
to
a
single
compartment
for
its
internal
bookkeeping
of
what
modules
it
knows
about
by
by
what
things
it's
been
asked
to
load
what
things
it
has,
what
things
that
has
successfully
loaded
and
what
things
that
has
successfully
begun
to
execute
a
full
specifier
is
is,
is
a
catch
key.
A
A
partial
specifier
is
anything
else,
any
anything
that
is
not
full
and
and
the
and
an
import
specifier
is
a
specifier,
as
as
it
exists
in
the
import
statements
of
an
ecmascript
module
and
those
can
be
partial
or
full.
It
is
the
duty
of
the
resolve
hook
to
turn
partial
identifier,
partial
specifiers,
into
full
specifiers,
logically,
synchronously.
A
Yeah
I
this
this
being
a
glossary.
I
tried
to,
I
tried
and
fits
and
starts
to
sometime
it's
it's
to
declare
the
concepts
and
hope
to
eventually
associate
them
with
the
implementation
and
subsequent
slides.
I
probably
given
that
I
used
load
hook
to
disambiguate
load
in
the
next
slide.
I
probably
would
go
back
and
edit
this
to
say,
as
you
suggest,
resolve
hook
the
the
again
module
referrer
is
the
full
specifier
of
the
text
that
corresponds
to
the
text
of
a
module.
A
The
the
refer
is
not
intrinsic
to
the
text.
It
is.
The
referrer
requires
the
the
the
in
order
to
know
what
the
full
specifier
is
for
a
module.
It
must
be
taken
in
the
context
of
the
resolve
function
and
in
a
particular
compartment.
A
So
it
is
possible
for
the
text
for
the
text
of
a
module
to
be
to
have
different,
corresponding
full
specifiers
in
different
compartments,
which
is
a
which
is
something
that
modibles
xs
takes
advantage,
or
at
least
exposes
the
ability
to
do,
and
importantly
does
because
it
that
is,
that
is
the
necessary
feature
for
some
things
that
you
need
to
do
in
that
environment.
The
the
module
is
so
so
resolved
resolve
produces
full
specifiers,
given
an
import
and
specifier
and
module
refer.
A
Those
are
concerns
that
are
delegated
to
a
particular
implementation
of
resolve,
and
it
is
in
in
the
context
of
a
particular
resolve
function.
Those
functions
are
free
to
those.
Those
terms
relative
and
absolute
are
free
to
mean
different
things.
This
is
important
because
a
url
has
a
different
meaning
of
relative
than
than
a
node
module,
a
module
specifier
and
the
note
in
the
context.
I
think
that
separation
is.
I
think
that
separation
is
really
good.
I'm
glad
you
did
that.
A
Thank
you
that
that,
to
be
clear,
you
is
not
me
in
this
case.
This
is
this.
Is
this
is
the
the
api
I
inherited
from
bradley
and
and
mark
when
I,
when
I
got
to
agoric-
and
I
think
that
yes,
they
they
did.
I
I
saw
when
I
arrived,
that
they
were
wisely
in
the
process
of
transitioning
to
this
terminology,
and
the
relative
specifier
and
absolute
specifier
in
node
have
very
specific
meanings
that
are
not
compatible
with
the
web
at
large.
B
Yeah
and
just
for
the
to
get
the
history
straight
here,
salah
and
michael
thicke,
more
than
me.
A
Wonderful
go.
A
Sometimes
these
things
get
lost,
so
the
the
going
on
a
load
hook
is
a
is
a
an
asynchronous
function
that
is
an
optional
and
an
optional.
It
is
necessary
for
a
compartment
to
do
dynamic,
module
loading
and
it
is
a
an
option.
So
it
is
an
optional
constructor
argument
of
the
of
a
modular
compartment
api
that
that
is
not
named
load
hook.
Importantly,
to
be
clear,
the
gl,
the
glossary
is
deliberately
separate
from
the
implementation.
A
At
the
moment
it's
called
import
hook,
but
to
for
clarity
it
is
a
load
hook.
It
is
responsible
for
locating
retrieving
parsing
and
analyzing
the
dependencies
of
a
module
record
or
module.
Specifier
importantly,
the
locate
part
is
is,
is
may
be
asynchronous,
which
means
that
it
is
possible
for
the
locate
hook
to
deal
with
redirects
and
canonicalization
of
the
module
specifier
to
the
corresponding
module
location.
The
module
location
is
a
domain.
A
That
is
a
separate
concern
from
the
compartment
api
because
it
might
be
a
file
system,
it
might
be
the
web,
it
might
be
a
zip
file
and
and
the
compartment
api
is
sufficiently
general
to
straddle
those
distinctions
by
not
concerning
itself
with
the
concern
of
location.
B
For
that
first
bullet,
just
to
recapitulate
the
where
it
says:
module
specifier
at
the
end
of
that
bullet
that
should
read
full
module,
specifiers,
always
specifically
a
full
module.
Specifier,
that's
fed
into
the
logo.
A
Right
load
is
load
is
a
facility
of
the
compartment
api
that
I'm
proposing
that
we
add
to
the
specification
that
recursively
induces
the
load
hook
to
obtain
the
entire
working
set
of
a
of
of
the
module
system
for
a
particular
entry
point,
and
the
entry
point
is
is:
is
the
the
argument
to
import
essentially
equivalent
to
the
argument
to
import?
A
It
is
a
full.
It
is
a
full
module,
specifier
pardon
in
the
compartment
api.
Yes,
it
must
be
a
full
module
specifier,
and
this
does
all
of
the
necessarily
asynchronous
portion
of
of
loading
a
module
and
it
does
not
execute
the
module
executing
meaning
actually
evaluating
the
code
of
the
module
in
the
context
of
that
compartment
with
its
globals
etc.
A
A
static
module
record
is
an
opaque
object
that
captures
the
analysis
of
a
module,
that
is
to
say
when
you
take
when
you
take
the
text
of
a
module
in
a
particular
location,
and
this
is
the
point
where
location
does
become
something
that
is
meaningful
to
the
compartment
api.
It
gets
revealed
potentially
as
import
meta
url
and
gets
import
and
gets
revealed
as
the
the
location
strings
and
error
stacks.
The
that
you
get
a
static
module
record.
A
The
static
module
record
is
an
is
captures,
but
does
not
expose
methods
for
the
behavior
and
analysis
of
of
the
of
parsing,
a
module
before
executing
it
and
reveals
what
its
imports
exports
re-exports
and
and
then
can
be
used
to
load
that
module.
The
only
way
to
execute
it
is
to
return
it
from
a
load
hook
to
the
compartment
api.
A
Yes,
it's
essentially,
it
is
a
spiritual
equivalent
to
a
function
constructor
that
in
in
that
it
could,
but
it
does
not
actually
expose
the
api
of
calling
it.
It
just
gives
that
behavior
to
it.
The
the
compartment
api
takes
that
and
then
is
able
to
execute
it
later,
possibly
possibly
in
multiple
compartments
at
different
times
or
not
at
all.
B
It's
multiple
instanceable,
which
makes
it
very
different
than
the
concept
in
the
tc39
ecma-262
spec.
The
concept
called
a
module
record,
which
starts
off
only
with
the
static
information
and
mutated
into
an
instance
and
therefore
cannot
be
multiple
instantiated.
This
one
stays
static
and
the
instance
is
completely
different.
A
So
the
static
module
record
is
also
very
specific
to
ecmascript
modules
and
it
does
support
late,
binding
and
because
late
binding
is
a
very
tightly
coupled
concern
to
the
implementation
of
an
engine
and
that
there
is
no.
There
is
no.
A
There
is
no
standardizable
behavior
for
lake
binding
for
the
compartment
api,
so
it
it
omits
that
and
leaves
that
entirely
to
the
host
to
define
so,
which
means
that
it
is
only
suitable
for
ecmascript
modules.
A
But
in
contrast,
we
do
need
to
be
able
to
support
third-party
modules
that
are
not
ecmascript
modules,
and
for
that
purpose
we
have,
we
are
going
to
propose
the
addition
of
a
static
module
interface.
If
you
will
name
is
to
be
decided,
I'm
suggesting
interface,
because
it
is,
it
is
a
shape
of
an
object
that
the
the
compartment
would
be
able
to
use
that
object,
may
explicitly
on
its
surface
declare
what
its
imports
re-exports
and
exports
are
in
a
way
that
it
can
be
linked
with
each
with
these.
A
Such
modules
can
be
linked
with
each
other
and
esm,
and
it
would
importantly
did
not
would
not
have
the
facility
for
supporting
late
binding
go.
B
A
Right,
I'm
also
unclear
about
where
this
the,
where
262
stands
on
this,
but
I
can
say
that,
where
the
compartment
api
stands
on,
this
is
that
the
static
module
record
constructor,
which
we
are
proposing
to
provide
as
a
global
to
make
available
in
the
global
namespace
tentatively
literally
global,
would
throw
an
exception
if
the
module
is
syntactically
invalid,
which
means
that
it
and
and
because
that
function
is
intended
to
be
called.
Since
that
construct
is
intended
to
be
called
in
the
context
of
a
load
hook.
B
There's
a
lot
of
I
can.
I
can
help
clarify
what
the
ecmo
262
semantics
are
of
what
follows:
if
the
module
felt
it's,
it's,
it's
actually
a
well-thought-out
scenario.
C
Okay,
as
as
long
as
it's
well
thought
out,
I
I'm
confident
I
don't
need
to
understand
it
this
minute.
I
just
want
to
make
sure
that
it
is
on
the
radar
of
those
who
have
to
actually
deal
with
this.
D
Yeah
so
historically,
we've
tried
to
actually
loosen
the
air
conditions,
enactma
262,
because
node
wanted
to
do
some
stuff
that
required
a
late
module
graph
resolution,
basically
currently
as
specified
since
the
modulograph
must
link
as
an
early
step
early
errors,
actually
fire
during
the
linking
of
the
module
graph
across
the
entire
graph.
D
D
So
this
is
up
to
the
engine.
Currently,
you
don't
actually
specify
anything
about
the
load
mechanism
in
ecma-262
itself
for
v8.
You
would
get
errors
at
different
points
in
time.
Actually,
and
then
you
have
to
write
your
loader
that
it
properly
propagates
the
errors.
D
Well,
I
can
give
a
more
concrete
example:
let's
say
we
have
a
module.
A
and
a
dependency
b
can
actually
start
loading
b
before
you
have
finished
parsing
a
and
so
at
that
point
you
can
have
early
errors
due
to
syntax
or
to
linkage
in
b
that
propagates
earlier
than
the
load
error
in
a.
D
B
D
D
Yes,
that
is
correct,
so
that
would
be
afterload.
That
is
the
only
edge
case.
I
can
really
think
of.
B
A
Cool
the
this
is
this
is
good
because
I,
if
that's
the
case,
then
I
see
no
need
for
any
further
complication
of
this
api.
If,
if
it
were
possible
for
an
incoherent
module
graph
survive
load,
which
I
can
see
being
desirable,
I
I
have
done
that
in
a
previous
implementation
of
a
module
system
in
order
to
gloss
over
certain
common
js
deficiencies
with
false
and
false
positives
and
false
negatives
in
heuristic
static
analysis
which
which
might
be
useful
to
propose.
A
But
if
that,
if
that
is
a,
if
that's
a
feature
where
we
want
a
potentially
incoherent
graph
to
survive
load
into
into
the
import
execution
phase
the
initialization
phase,
then
we
would
need
a
way
for
the
static
module
record
to
communicate
forward
that
it
was
constructed.
But
with
an
error
that
should
be
later
thrown.
A
If
it
were
to
be
executed,
which
also
doesn't
actually
require
any
change,
because
that
is
that
is
possible
to
capture
in
the
behavior
of
initial
initialization.
B
A
Yeah
yeah,
okay,
I
think
we're
in
a
good
place.
Thank
you
for
the
question
chip.
It
was
interesting,
yeah,
gizenheit,
sorry,
okay,
so
live
binding.
Is
a
subjectively
dubious
feature
of
ecmascript
modules,
where
changes
to
an
exported
variable
can
be
observed
in
the
scope
of
an
importer,
and
this
is
this
is
the
interesting
feature
of
esm,
where
conceptually
to
the
programmer
and
imported
an
exported
variable
exists
in
a
chunk
of
shared
scope
between
two
two
scopes.
B
So
the
perspective
we're
taking
here
is
that
we're
only
ever
going
to
to
try
to
support
live
bindings
from
esm
to
esm
and
as
we
as
other
languages
and
other
forms
of
module
come
to
play
within
the
system
through
the
static
module
interface.
B
Wasm
modules
do
not
have
live
bindings.
The
the
the
json
modules
that
people
are
talking
about
do
not
have
live
bindings.
Obviously,
and
commonjs
has
no
wide
bindings.
D
So
that's
a
little
bit
complicated
node
creates
a
facade
around
common
js
that
can
have
live
updates.
We
do
this
for
the
built-ins,
there
is
a
what
is
it
called
sync
all
built-in
modules
on
the
module
module.
A
This
is,
this
is
not
a
problem,
or
at
least.
D
No,
this
describes
a
workaround,
so
even
if
we
don't
directly
support
it,
you
can
recreate
live
bindings
by
creating
a
facade
around
your
modules
and
ensuring
that
only
the
the
facade
is
reachable.
A
So
this
is
that's
an
interesting
qu.
This
raises
interesting
questions
because
it
is,
it
has
become
recently
possible
in
in
node
for
named
exports
from
common
js
to
be
realized
as
named
imports
in
esm.
A
If
so,
the
the
money
question
is
like
whether
live
bindings
are
are
supported
at
all,
for
between
common
js
and
esm
is,
if
I
were,
to
have
to
asynchronously
in
a
future
turn
change
a
property
of
the
object
exported.
The
exports
of
a
common
js
module
would
a
module
that
imports
that
that
property
of
that
object
by
name
realize
the
change
in
its
scope.
B
I
would
advocate
that
the
answer
be
no.
If,
if
we
can,
if
the
answer
to
that
could
be
no,
I
would
be
very
happy.
D
The
sure
it
is
no,
we
actually
tried
to
do
this
with
the
node.js
built-ins,
but
it
caused
problems
due
to
getters
and
setters
actually,
and
so
we
actually
ripped
that
out
and
we
had
this
utility
method
produced
that
will
manually
update
all
the
live
bindings.
Whenever
you
call
it,
it
is
not
reactive,
perfect,.
C
It's
worth
noting,
though,
that
the
synthetic
the
synthetic
module
record
in
v8,
which
is
a
type
of
module
record
that
is
separate
to
the
the
standard
source
text
module
record,
does
support,
live
binding
updates.
So
it's
a
synthetic
module
api
that
supports
updating
live
bindings
through
a
callback
function
which
can
sort
of
update
any
of
the
exports.
A
C
So
could
I
could
I
chime
in
quickly
it's
important
to
contrast
what
what
a
live
binding
in
an
ecmascript
module
is
relative
to
the
it's
basically
a
top-level
declaration
of
a
of
a
name
that
is
imported.
It's
a
one-way,
and
it's
really
not
a
you
know
observable
here,
as
in
reflected
as
opposed
to
you
don't
get
like
a
like
a
a
way
to
know
when
it
changes
it.
C
Just
it's
a
one-way
change
that
will
happen
when
you
try
to
compare
this
to
how
an
export
is
on
in
a
common
js
context
as
a
as
a
developer
who's
using
common
js
who
understands
what
an
exports
object.
B
C
Yeah,
like
there's
no
there's
no
parallel,
and
I
think
it
would
be
a
big
mistake
to
to
you
know
if
you
can
emulate
it,
you
will
likely
be
making
someone
unhappy,
but
you
wouldn't
be
aware
because
they're
following
you
know,
concepts
of
the
javascript
language
and
they're
treating
this
as
an
object.
So
so
I
think
yeah.
Maybe
what
we
want
to
do
is
introduce
a
contrasting
binding
that
could
allow
for
for
a
different
type
of
binding
that
that
you
know
reflects
a
common
js
object.
C
You
know
export,
but
I
wonder
if
we
need
that
in
the
future
you
know.
Hopefully,
people
are
transitioning
away
from
from
you
know,
I
guess
modules
that
were
there
before
the
language
had
a
module
system.
B
Yeah,
I
would
like
to
see
this
group
take
the
stance
that
we
just
don't
need
to
support
anything
like
live
bindings,
except
for
this
one
case
of
esm
desm,
and
that
the
simple
module
interface
that
chris
will
be
presenting
is
really
going
to
be
the
you
know
the
limits
that
everything
other
than
esn
has
to
fit
within,
which
just
supports
exporting
values
does
not
support
an
exporting
plane.
B
C
I
I
have
a
continuing
point
of
confusion
as
I
have
for
various
aspects
of
this.
I'm
sorry,
I'm
I'm
unclear
on
what
the
phrase
changes
to
an
exported
variable
even
means.
A
C
So
we're
not
talking
about.
We
we're
just
talking
about
an
assignment
to
a
variable,
we're
not
talking
about
redefining
a
symbol.
B
Okay,
you
read
the
imported
variable
before
and
after
the
assignment,
the
imported
variable
will
always
have
the
same
value
as
the
exported
variable.
So
when
the
exported
variables
change
the
important
variables
change
and
the
model
is
that
you've,
what
you've
imported
is
simply
a
name
for
the
same
changeable
location.
B
A
A
A
Yep,
okay,
so
once
more
with
feeling
we're
almost
through
the
glossary
to
execute
a
module
is
to
to
run
it
from
top
to
bottom
quote:
scare
quote:
synchronously
the
shim
at
the
moment
is
synchronous,
but
only
because
we
haven't
dealt
with
the
last
item
on
this,
which
is
top
level
await
which
we'll
get
to
import
is
an
asynchronous
function,
that
loads
asynchronously
and
then
synchronously
executes
the
module
and
its
transitive
dependencies
in
a
particular,
well-defined
semi-non-deterministic
order.
Once
you
take
top
level
away
into
account,.
A
Yeah,
it's
it's
bradley
knows
this
better
than
I
do,
because
I
haven't
gotten
around
to
implementing
it
myself
yet.
But
my
impression
is
that
there
are
pools
of
reason
where
things
are
deterministic
and
synchronous.
If
linkage
between
the
modules
and
if
there's
a,
if
there's
a
subset
of
the
modules
that
are
that
are
not
that,
have
no
asynchrony
among
them
that
they
will
be
executed
in
a
deterministic
order
and
but
where
there
is
a
top
level
weight
it.
B
Yeah,
this
is
another
place
where
there's
a
very
well
thought
out:
ethnic
262
semantics
of
what
happens
when
there's
errors
during
initialization
and
the
the
answer
here
is
very
different
than
the
linkage.
The
linkage
errors
are
contagious
across
the
entire
graph.
B
The
initialization
errors
are
bottomed
up
by
strongly
connecting
components
as
the
unit,
so
in
other
words,
if
there's,
if
there's
an
import
cycle,
if
anything
in
the
import
cycle
errors,
then
the
entire
cycle
is
marked
as
erroneous,
but
that
happens
bottom
up
by
cycle.
A
Yeah
yeah,
so
to
be
clear,
import
is
a
composite
function
of
load
and
execute
or
initialize
or.
However,
you
wish
to
call
it
I'm
going
to
call
it
execute
for
the
purposes
of
this
presentation
and
may
be
convinced
to
revise
it
for
future
communication.
Execute
does
not,
as
a
name
appear
anywhere
in
the
apis.
You
only
get
load.
If
my,
if
my
proposal
goes
through,
you
will
have
load
and
you
will
have
import
which
closes
overload
and
execute.
A
A
Yes,
it
only
takes
full
specifiers.
The
import
now
is
a
thing
that
is
currently
in
our
proposal,
which
I
propose
that
we're
going
to
need
to
strike
and
the
reason
being
that
it's
that
its
interface
is
not
observably
different
than
import
in
the
future.
Once
you
take
top
level
await
into
account
the
but
import
now
is
effectively
the
execute
api,
as
currently
proposed.
B
A
And
because
execute
cannot
succeed
if
it
has
not
previously,
if
the
working
set
has
not
previously
been
loaded
in
its
entirety,
import
now
is
obliged
to
throw
an
error
if
load
has
not
completed.
A
Yes,
so
yeah
and
then
top
level
of
weight
throws
throws
a
wrench
into
all
of
this,
because
it
obliges
the
execute
method
to
be
asynchronous.
Therefore,
there
is
no
user
perceivable
difference
in
the
api
of
import
and
import
now
and
which
is
to
say
that
import
would
be
required.
There
is
some
wiggle
room
here.
A
There
might
be
a
reason
to
keep
the
distinction,
but
I
don't
like
it,
but
let
me
explain
it
is
possible
that
the
inter
that
the
so
import
returns,
a
promise
for
a
module
namespace
right
import
now
returns
presently
is
specified
to
return
a
namespace
object
directly.
A
B
Okay,
so
peter,
I
very
much
like
feedback
from
you
on
this,
because
the
the
inclusion
of
import
now
originally
came
due
to
requests
from
model.
C
Yeah,
I
I
mean
I'm
not,
I
I'm
not
in
a
place
to
give
detailed
feedback
on
this
today,
but
but
we.
D
C
I
don't
want
to
be
too
too
reactionary
about.
A
It
yeah
absolutely
and
we
are
receptive
to
whatever
whatever
you
conclude,
we're
very
interested
in
hearing
what
you
can
include
after
having
some
time
to
mull
over
it.
So
we
are
out
of
time
and
we've
been
again
and-
and
we
have
gone
over
absolutely
none
of
the
slides
that
existed
a
week
ago,
which
is
fun
but
I'll,
be
sure
to
write
more
no.
A
Yeah
good-
and
it
was
a
valuable
exercise
in
going
through
the
process
of
clarifying,
because
this
all
needs
to
be
written
down
in
a
place
where
other
people
can
find
it.
A
All
right
well
to
be
continued
I'll
press,
the
stop
recording.
Thank
you.