►
From YouTube: SES Meeting: Deferred Execution
Description
Wherein we discuss Yulia Startsev’s most recent change to the proposal for synchronous deferred execution of modules, wherein the read barrier is delimited on property access and does not exist for module lexical bindings. We begin to consider the possibility of programs that are correct in isolation and broken in composition with this feature.
A
Welcome
to
the
Sesame
meeting,
it's
November
9th
of
2022
and
our
agenda
is
liked
today,
but
yesterday,
at
the
modules
Harmony
call
you
Leah,
presented,
deferred
execution
of
modules
and
I
will
not
be
able
to
do
justice
to
the
presentation
that
she
provided.
But
you
may
recall
the
presentation
that
she
last
gave
about
the
topic
at
plenary,
allowing
allowing
me
to
wave
my
hands
a
little
bit.
A
The
idea
is
motivated.
So,
let's
start
with
the
motivation.
The
motivation
is
that
there
are
many
code
bases
that
are
currently
stuck
on
common
JS,
because
they
cannot
move
to
esm
without
suffering
a
performance
penalty
for
the
execution
time
of
conditionally
needed
conditional,
runtime,
conditionally
needed
dependencies,
and
the
only
obvious
mitigation
today
is
that
anything
that
depends
on
conditionally
executed.
A
Dependencies
has
to
be
async
today,
because
because
the
viral
contagion
of
an
async
Dynamic
import
is
involved,
and
that
is
intractical
intractable,
because
currently
it's
sufficient
in
the
common
JS
scenario
to
say
to
defer
the
required
call
conditionally,
which
allows
the
code
to
be
loaded
but
not
executed
until
it's
actually
needed.
B
The
defer
making
the
required
conditional
doesn't
load
the
code
before
it's
needed.
It
only
loads
and
executes
the
code.
If
it's
needed
right,
I
mean
if
you
don't
if
you,
if,
if
you
don't
call,
if
you
don't
make
the
required
call,
you
don't
load
the
code.
A
That
is
true
on
node,
because
node
has
a
synchronous,
implementation
of
the
module
loader
but
require
when
require
when
common.js
is
used
in
on
the
web.
It
must
be
bundled
and.
A
Bundled
we're
using
heuristic
static
analysis
of
require
calls
in
order
to
load
anything
that
can
be
loaded
at
times
and
conditionally
executing
it
at
runtime,
okay,
which,
which
is
as
designed
it
was
intended
to
be
used
to
that
way,
and
node
just
did
its
own
thing
for
its
own
reasons.
A
The
so.
The
upshot
of
it
is
that
the
that
Mozilla
is
using
this
internally
to
their
engine
and
they
are
using
asynchronous
file
system
and
they
are
moving
to
esm
with
an
a
sync
with
a
synchronous,
implementation
of
esm's
module,
loader
and
then
their
use
cases
is
is
provided
for
they
found
a
way
out,
but
they
Julia
is
hoping
to
ex
to
propose
a
more
General
solution
for
esm,
and
that
is
that
they're
tentatively
calling
this
deferred
execution
and
in
the
previous
rendition
of
The
Proposal.
A
This
is
an
extension
to
esm
such
that
there
would
be
a
read
barrier
for
any
of
the
imported
lexical
names
of
a
laser,
a
defer,
a
deferred
execution
module
such
that
the
body
of
the
of
the
body
of
the
Deferred
module
will
be
executed
at
the
time
of
the
first
read
of
anything
that
it
provides.
B
A
And
that
is
the
feedback
that
Yulia
recalls
from
the
last
meeting
and
has
a
clever
restriction
that
she
intends
to
propose
to
the
to
this
that
such
that
it
would,
instead
of
having
a
read
burial
a
read
barrier
on
a
lexically
named
binding
deferred
to
defer
the
execution
of
module,
you
would
have
to
receive
a
lazy
namespace
object.
They
proxy
for
the
namespace
object
for
a
proxy
for
the
subset
of
the
namespace
that
you
select
to
import
such
that
every
such
that
the
Deferred
execution
still
has
reentrancy
but
syntactically.
A
So
the
idea
is
that
you
would
get
this
lazy,
namespace
object
and
say
namespace,
dot,
name
and
the
first
time
any
of
those
names
are
accessed
through
property
access
that
causes
the
execution
of
the
the
Deferred
module
body
on
your
stack,
and
so
the
things
that
I
brought
up
at
yesterday's
meeting
were
that
this
introduces
some
interesting
side
effects,
one
of
which
is
that
if
an
error
is
thrown
by
the
execution
of
the
body
of
the
Deferred,
the
Deferred
module
that
the
that
the
Deferred
module
would
be
obliged
to
capture
some
stack
frames
from
the
the
first
lazy
execution
module
that
accessed
a
property
of
that
different
of
the
Deferred
module.
A
A
So
there
are
a
number
of
possibilities
for
it.
One
possibility
is
that
the
exception
includes
stack
frames
from
the
importing
module
and
those
would
be
leaked
to
any
other
module
that
does
a
dynamic
import
of
it.
A
B
Sorry
are,
there
is
the
only
exception
issue
the
cut
the
confidentiality
leak
of
the
content
of
Stack
frames,
because
the
I
mean
in
general,
you
know
with
with
within
a
you
know,
there's
there's
still
the
ongoing
issue
about.
What
do
we
want
to
do
at
Round
boundaries
with
regard
to
Stats
to
race
privacy,
but
within
a
realm
there
is
no
stack
Trace
privacy
and
until
you
turn
on
lockdown
and
on
lockdown,
we
got
we.
We
need
to
specify
what
it
is.
We've
implemented.
D
A
D
Currently,
the
the
top
level
module
evaluation
is
on
the
clean
stack,
always
whether
that's
through
Dynamic
Imports
or
static
Imports.
Obviously,
okay,.
B
But
but
the
the
the
the
reason
that's
important
is:
is
isolation
of
side
effects,
in
other
words
the
whole
the
whole
protection
against
a
re-entrancy
attacks.
B
The
that's
the
thing
to
focus
on
the
the
the
the
make
stack
traces,
making
it
visible.
What
you're,
making
visible
is
that
you're
in
a
fatal
situation.
The
problem
is
that
you're
in
a
fatal
situation,
not
that
you've
made
it
visible.
A
Yes,
so
the
so
I
believe
my
concerns
regarding
exceptions
are
fully
addressable
and
there
are
many
ways
to
address
it.
I
think
it's
acceptable
to
leak,
I
think
it's
acceptable
to
leak
and,
in
fact,
desirable
to
leak
the
the
importing
module
stack
frames,
because
that
might
be
useful
for
diagnosis
of
hey.
Why
did
that
thing?
A
Break,
but
but
yeah
the
re-entrancy
issue
is
and
whether
the
question
is
for
Mark
that
I
can't
answer
is:
does
limiting
re-entrancy
to
occur
on
the
dot
of
on
on
accessing
the
property
of
a
lazy
namespace
object
sufficient
to
assuage
concerns
about
re-entrancy
in
general,
I'd
like
to
understand
the
way
the
re-entrance
issue
is.
D
Because
the
module
being
evaluated
can
only
have
access
to
what's
in
the
global
and
cause
re-entracy
through
for
anything
on
the
global,
because
every
everything
else,
by
definition,
would
have
to
be
lazily
loaded
with
it.
Foreign.
D
Yes,
I
I
understand,
but
any
re-entrancy
would
have
to
come
through
through
a
global
access.
As
far
as
I
understand.
B
In
the
absence
of
laziness
and
and
in
the
absence
of
Cycles
modules,
initialize
in
a
bottom-up
order
by
the
import
graph,
for
if,
if
lazy,
module,
a
Imports
module
B,
when
does
module
B
get
evaluated.
D
I
assume
just
before
module
a
gets
evaluated.
B
D
The
whole
subgraph
I
believe
the
whole
subgraph
would
be
evaluated
it's
following
the
same
constraints
as
today,
but
during
that
lazy
evaluation,
Yulia.
A
Has
investigated
this
very
thoroughly
the
and
has,
and
has
very
specific
plans
about
how
to
address
things
like
what,
if
one
of
those
modules
has
top
level
await
and
when
and
such
okay.
B
So
here's
another
so
here's
another
potential
stateful
coupling
that
can
lead
to
re-entrancy
problems
which
is
module
A
and
B.
Both
import
module,
C
module
B,
is
deferred,
so
A
and
C
are
all
evaluated
before
B
is
loaded.
B
I'm!
Sorry
before
B
is
evaluated,
then
Within,
you
know
with
within
a
term
within
while
there's
a
stack
going
on.
While
something
might
be
going
on
with
the
state
of
C.
B
Somebody
now
initiates
a
the
the
Deferred
evaluation
of
B,
so
deferred.
Evaluation
of
B
is
happening
while
C
is
active.
B
by
importing
C
has
access
to
C
synchronously
during
this
time.
That's
that
can
be
stateful
interference
on
the
state
of
C.
B
So
so,
basically,
the
the
the
the
the
property
of
imports
that
two
Imports
of
the
same
thing
give
you
the
same.
Stateful
instance
gives
you
another
source
of
of
effectively
Global
helpline
everything.
A
So
the
question
is:
does
introduce,
does
introducing
deferred
execution.
A
D
Get
back
to
this
to
this
example,
if,
if
C
is
on
the
stacks
and
the
and
the
laziness
is
caused
by
a
lazy
importing
B,
that
means
CS
codes
into
a
function
of
a
that
causes
the
laziness
to
trigger.
So
in
the
first
place,
C
already
opened
itself
through
re-entrancy.
D
Function
in
a
that
would.
D
E
I
think
they
they
want
me
over
when
Julia
was
explaining
the
reality
of
the
situation
where
you
want
to
use
the
Lazy
by
the
lazy
required.
The
next
turn,
because
you
use
import
as
a
promise
based
API
to
initialize
the
lazy
module,
and
that
requires
significant
changes
across
the
border.
E
I
think
I
understand
that
I
I'm
sympathetic
with
that
point
of
view,
and
so
these
synchronous
manner
of
initialization
seems
to
be
a
lot
easier
for
developers
to
modify
their
code,
make
some
other
pieces
of
the
program
to
to
be
lazy
and
still
not
having
to
change
everything.
I.
B
Mean
it,
it
might
be
that
it's
that
there
it
might
be
easier
when
it
works,
but
still
be
fatally
and
defensible.
So
so
you
know,
let
me
acknowledge
that
when
it
works,
I'm
sure
it's
easier,
but
that
doesn't
that
doesn't
resolve
the
hazard
issue.
B
Well,
so
this
is
the
first
I'm
really
trying
to
think
it
through,
and
this
answer
that
that
Chris
just
gave
about-
or
was
it
Matthew
Matthew
just
gave
about
in
order
for
the
for
in
in
the
diamond
import
case?
In
order
for
the
particular
case,
I
was
worried
about
to
be
a
problem.
You
would
have
to
have
C
calling
out
to
a
which
that
seems
right.
So
I
don't
have
it
thought
through
there?
B
Might
it
might
be
okay,
but
I'm
certainly
have
no
confidence
at
this
point
that
that
it's
okay
and
it's
it
certainly
seems
like
a
very,
very
dangerous
area.
You're
you're
losing
all
of
the
simple
reasoning
about
isolation
of
of
acyclic
module,
initialization.
A
B
B
Okay,
so
we've
got
an
initial
module,
I
I
for
initial
that
Imports
a
and
lazy
Imports
B.
By
the
way
who
says
that
the
import
is
lazy,
is
it
the
Importer
or
the
importee?
The.
B
So
I
Imports
a
and
I
lazy,
Imports
B,
a
Imports
C
and
B
Imports
C.
B
Thank
you
and
then
the
the
remaining
question,
which
is
where
this
delicate
defense
may
or
may
not
work
is
what
is
the
problematic
thing
that
happens
that
triggers
the
evaluation
of
B
and
can
that
happen
with
C
frames
on
the
stack
without
they're
having
without
there
being
any
further
Imports
beyond
the
state,
the
ones
that
we
stated
here
and
I
think
the
answer
is
yes,
because
the
call
out
is
not
via
a
cyclic
import
and
if
the
call
out
is
not
via
cyclic
import
and
its
cause
and
it's
causing
something
other
than
separated
bottom-up
evaluation,
then
it
is
violating
a
a
State
separation
constraint.
B
Right,
a
call
out
is
not
a
cyclic
import.
A
call
out
is
just
a
runtime
runtime
interaction.
E
B
But
I
could
I
I
after
importing
a
could
pass,
2A
a
closure
created
by
I,
which
a
calls
and
then
during
the
call
from
a
or
that
you
know,
or
that
that
in
fact
it
could
be
passed
through
a
to
c
so
c
calls
a
closure
callback
created
by
I
and
then
the
evaluation
of
B
is
triggered
by
the
Callback.
E
B
D
D
I
understand
that
that
is
only
relevant
to
the
top
level
of
that
module
if
it
doesn't
affect
the
the
caller.
It
only
affects
the
colleague.
D
D's
execution,
the
B
can
sense,
indeed
that
it
was
called
with
a
stack,
but
it
at
the
end
of
the
day
from
C's
point
of
view,
or
whoever
else
point
of
view
is,
is
just
another
function
called
another
evaluation
that
happens
behind
a
function.
Call
no.
B
But
the
thing
is:
B
has
access
to
to
C's
exports,
because
B
also
imported
C
during
B's
evaluation,
which
might
happen
during
seize
evaluation.
D
E
I
I
think
I
think
I
get
it
I,
think
I
I
think
I
get
what
you're
saying
you're
doing
something
you
see,
and
that
causes
the
synchronous
evaluation
of
a
module
and
that
otherwise
was
it's
not
possible.
You
know
it's
not
possible
today
to
see
that,
but
I
think
Julia
convinced
me
yesterday
during
the
meeting
and
again
I'm
I'm
only
spending
like
I
would
say
a
couple
of
hours.
Thinking
about
this,
the
she
convinced
me
that
first,
this
is
not
different
from
B
I
mean
it's.
E
Another
example
that
she
uses,
like
you,
just
have
a
object
that
has
properties
on
it
and
you're
accessing
those
properties,
whether
those
are
accessors
or
it
is
a
proxy
or
something,
and
something
is
happening
when
you're
accessing
the
property.
There
is
already
a
a
a
intuition
about.
E
B
The
the
the
the
that
the
the
fact
that
the
side
effects
happens
during
the
that
side
effects
happen
during
dot
I
agree
that
that's
not
a
problem,
because
it's
already
the
case
that
side
effects
happen
during
Dot,
but
but
C
used
to
be.
You
know
c
as
imported
right,
a
b
and
c.
None
of
them
said
anything
about
being
lazy.
They
they
were
all
coded
under
normal
esm
assumptions
about
the
protection
of
side
effects
from
each
other
when
code
in
C
uls
a
callback.
D
But
you
just
deferred
the
problem
to
I
I
I
must
have
given
away
to
a
to
reaching
to
be
somehow
to
a
function,
call
right
and
it
doesn't
at
some
point:
you're
you're,
just
ex
you
just
have
to
rely
on
on
something.
You
don't
control
and
you
haven't
written
to
open
that
up
and
if
you
have
written
everything
you
you
are
aware
of
of.
B
If
you're
omniscient
then
nothing's
a
hazard,
because
because
you
know
what
you're
doing
you're
not
attacking
yourself,
the
you
know
all
of
the
cases
not
just
from
a
security
point
of
view,
but
from
a
modularity
and
Bug
point
of
view
are
where
you
know
different
part
pieces
of
code
were
coded
under
different
assumptions
that
would
normally
hold
and
then
the
those
those
assumptions
can
be
broken
by
someone
who
should
not
have
been
in
a
position
to
break
them
or
by
someone
who
engaged
in
a
pattern
that
should
not
have
broken
assumptions,
but
did
right.
B
D
What
I'm
saying
here
is
foresee
to
expose
itself
to
a
re-entrant
cn2c,
and
it
must
be
calling
out
to
something
that
is
not
under
its
control,
and
that
is
a
function
in
I
that
function.
I
could
have
imported
C,
directly
and
re-entrine
and
then
Oriental
and
CG
on
it.
So
it
doesn't
need
to
do
anything
lazy.
It
would
be
for
that.
E
I
think
Mark,
you
were
saying:
if
you
eliminate
I
from
the
picture,
there
is
no
I,
then
she
will
never
really
be
able
to
do
anything
on
me
like
it
doesn't
know
about
me
at
all
right.
It
has
to
go
through
something
that
allows
it
to
see.
There's
something
there.
That's
me
that
is
doing
something
so
yeah.
B
E
I
think
I
mean
it's
able
I
think
I'm.
Still
apart
from
really
understand
all
these
at
first
glance,
I
I
even
questioned
whether
or
not
we
should
have
either
a
more
low-level
API
or
a
more
generic
API
that
allow
you
to
control,
because
this
is
really
just
a
mechanism
that
allow
you
to
execute
a
module
synchronously.
That's
all
it
is
all
the
other
syntax
and
others
just
for
that.
E
Just
for
that
to
be
able
to
happen
and
and
this
it
might
be,
that
more
low
level
API
can
be
used
by
some
of
the
other
mechanisms
that
we're
putting
in
place
with
the
layer,
zero
and
so
on
that
it
might
allow
you
to
to
emulate
these
and
do
this.
If
you
want
to
do
lazy
of
any
kind,
so
I'm
not
sure
alternative,
we
can
have
a
a
more
generic
API
that
just
simply
allow
you
to
say.
I
I
want
to
evaluate
these
right
now.
I,
don't
want
to
wait.
E
I
already
have
it
ready
somehow
model
in
terms
of
some
sort
or
something
so
yeah
I'm
still
far
away
from
also
I
agree
on
everything
here,
because
I
cannot
recently
in
about
all
the
the
cases,
but
at
first
glance
it
looks
like
they
might
be
up
to
something.
A
Let's,
let's
try
to
give
a
fair
shake
to
attempting
to
find
an
example,
and
the
criteria
of
the
of
of
the
of
the
example
would
be
a
module
or
set
of
modules
that
are
authored
in
isolation
coherently,
for
that
establish
a
plan
for
their
execution,
such
that
the
introduction
of
another
module,
that
lazy
lazily
depends
on
one
or
any
of
some
can
interfere
with
their
plan.
Okay,.
B
Good
that
I
think
that
that
that
that
is
an
accurate
representation
of
the
kind
of
case
that
I'm
worried
about.
A
And
so
I
don't
think
that
we've
run
this
particular
case
to
ground.
Yet
so,
let's
can
I
have
some
help
filling
out
at
least
a
hypothetical
direction
we
can
go
in.
That
is
likely
to
cause
likely
to
cause
a
plant
interference.
A
I
think
that
Matthew,
you
were
suggesting
that
c
dot
JS
would
provide
an
API
with
a
callback
yeah.
So
that's.
A
A
D
Need
to
take
a
call
back
that
needs
to
be
executed,
and
it
probably
needs
to
have
another
exports
that
also
interfere
with
some
shared
States
between
those
two
things,
and
that
is
for
expected
not
to
be
called.
A
Okay
and
we're
gonna
do
something
like
null
equals.
D
The
the
the
part
of
where
I
don't
follow
is
anyone
would
be
able
outside
of
the
set
of
trusted
on
of
authority
together,
module
will
be
able
to
import
call
me
so
I
I
can't
I
can't
imagine
something
further
here.
D
A
Shape
well,
let's,
let's
run
this
to
ground
a
little
bit,
so
the
the
premise
here
is
that
cjis
is
providing
an
API,
and
this
is
somehow
presumably
through
the
a
root
getting
into
the
hands
of
I.
Is
that
right.
A
A
B
Let
me
clarify
something
about
the
goals
here.
The
goal
is
not
it's
not
laziness,
laziness
is
a
means,
is
what
is
a
possible
means
to
the
goal?
The
goal
is
to
be
able
to
do
synchronous,
conditional
import
where
the
condition
depends
on
data
from
earlier
in
the
same
synchronous
execution.
Is
that
correct.
B
A
A
Yeah,
okay,
so
call
me
later,
maybe
is
providing
a
call
back
and
then
we
want
that
call
back
to.
C
D
By
the
way,
discussion
yesterday
was
that
you
can
have
a
freestanding
identifier,
cause
Side
Effects
by
just
installing
a
getter
on
the
global
disk.
D
Yeah
I
think
Nicholas
point
was
that
currently
in
the
identifier
that
is
actually
declared
module,
identifiers
are
actually
declared
and
they're
guaranteed
to
be
to
be
safe.
So
it's
it's
only
identifier
and
are
not
declared
in
the
local
that
that
may.
A
A
All
right
so
tell
me
more
about
how
this
might
break
an
invariant
established
by
the
plans
of
CJs.
A
D
The
whole
setup
here
I
think
I
is
probably
flawed,
because
anybody
couldn't
import,
B
or
C
or
and
so
on
and
and
Cole
and
perform
those
those
calls
in
the
first
place
without
any
lazy
Imports.
So
I
I,
don't
know
like
I
I.
A
Yeah
I
don't
see
it
either
not
from
this
particular
scenario:
Let's.
Let's
pop
the
stack
and
talk
to
Mark
about
alternative
approaches.
B
Yeah
so.
B
So
you
haven't
done
any
of
the
evaluation
that
you're
trying
to
avoid.
So
let
me
first
of
all
make
sure
that
that
I'm
understanding
the
motivating
problem
correctly
in
order
to
have
the
static
module
record,
you
have
to
have
loaded
the
you
know
the
module.
So
the
fact
that
the
loading
has
to
happen
ahead
of
time
is
not
what
we're
trying
to
avoid
correct
that.
A
A
The
time
spent
parsing
was
about
half
and
the
time
spent
executing
was
about
half,
and
that
was
significant
enough.
That
deferring
the
execution
of
things
that
are
not
needed
that
are
not
necessarily
needed
at
runtime
is
basically
a
2X
speed
up,
even
though
they
haven't
gotten
rid
of
the
load.
B
B
That
evaluation
call
evaluates
synchronously
evaluates
the
module
top
level
synchronously
during
the
call.
A
Tentatively-
and
this
is
likely
to
change
the
its
new
module
source-
oh
no,
it
isn't
even
necessarily
that
it
is.
The
import
hook,
returns
an
object
that
implements
a
that
provides
a
bindings
array
and
an
evaluator
execute
function
that
receives
an
internal
view
of
the
modules
module.
A
Module
names,
the
internal
module
scope,
I
forget
what
I
called
it
in
any
case,
it's
a
an
object
that
represents
the
internal
names
of
all
of
the
values
that
are
imported
or
exported
by
that
module
through
its
bindings.
A
A
You
are
not
in
a
okay,
so
you
could
do
that,
but
you
would
have
to
come
with.
You
would
have
to
have
your
own
copy
of
the
environment
or
the
the
module
and
import
namespace,
and
the
only
way
to
obtain
that
at
the
moment
is
by
implementing
this
particular
method,
and
it
will
be
called
on
an
empty
stack
by
the
dynamic
by
the
by
the
Machinery
underneath
Dynamic
import.
C
B
B
So
if
we
could
it's
okay,
so
this,
so
the
static
module
record
is
itself
a
first
class
runtime
value.
B
B
No,
let's
not
take
the
diamond
case.
Let's
do
something
else:
let's
have
a
I
Imports
a
and
a
in
Port
C.
Let's
just
make
a
new
diagram:
don't
don't
overwrite
that
dialogue,
I
Imports,
a
a
import,
C
I,
also
Imports
B
and
B
Imports
d.
B
Gets
D
you
had
to
correct
yes,
yeah
Okay,
so
during
the.
B
C
B
Runtime
value
such
that
later
in
the
execution
either
something
you
know
when
something
Imports
some
special
name
like
be
importing
d-
that
what
what
it
that
somehow,
it's
already
been
determined
that
what
d
means
when
B
Imports
d
is
the
static
module
record
that
had
already
been
determined
during
the
evaluation
of
a
or
C
or
something
probably
C
is
completely
unnecessary.
B
You
can
just
say
during
the
execution
of
a
the
the
the
correspondence
between
d
and
a
particular
static
module
record
gets
established
so
that
by
the
time
B
Imports
d,
it
which
static
module
D,
the
name
d
designates-
was
determined
by
a.
C
B
So
I'm
I'm,
not
I
I,
mean
I'm
saying
this
is
well.
First
of
all,
could
we
do
this
with
the
in
the
API
that
you
know
the
low
level?
You
know
module
loader
API
that
that
we've
already
designed?
B
C
E
Why,
in
order
for
you
to
trigger
the
synchronous
aspect
of
it,
you
had
to
do
something
like
import.sync,
something
like
that:
anyone
anyone,
a
new
Dynamic
API,
the
new
Dynamic
import
API
that
is
synchronously
like
be
import.sync
parenthesis.
Then
you
give
the
module
interns
to
it
and
something
like
that
might
might
be
analogous
to
what
you
will
be
able
to
do
with
the
syntax
of
their
proposing.
B
Okay,
but
the
import.sync
would
not
would
not
actually
I
mean.
This
is
only
solving
a
problem
if
the
import.sync
does
not
reintroduce
the
the
re-entrancy
Hazard.
So
the.
B
So
the
the
key
thing
about
the
graph
here
is
that
the
import
done.
B
B
So
the
the
the
important
question
is:
can
we
do
this
all
synchronously
with
our
current
API,
without
introducing
a
re,
a
re-entrancy
hazard?
B
So
if
there's
something
like
an
import.sync
import.sync
would
have
to
somehow
not
introduce
a
re-entrancy
hazard,
which
means
it
cannot
evaluate
the
thing
being
imported
during
the
import.sync,
which
sounds
like
it's
kind
of
violates
the
notion
of
import.sync.
So.
E
C
A
Yeah
and
all
of
the
import
now
variants
that
we've
seen
so
far
proposed
are
ones
where
import
now
will
throw
an
exception.
If,
if
the
the
graph
of
things
that
need
to
be
the
need
to
be
evaluated,
have
not
already
been
loaded
synchronous
or
have
not
already
been
loaded.
B
E
I
mean
I
mentioned
that
just
like
potential
apis
that
allow
you
to
say
that
was
what
I
was
saying
yesterday
in
the
meeting
that
can
we
have
a
more
genetic
mechanism,
they
they
only
describe
the
behavior
or
they
only
describe
the
the
Cloudy
version
of
these,
which
is
the
lazy
into
the
one
that
I
think
you
have
in
line
14
there,
the
import
boo
into
B
from
B
in
the
right
hand,
side.
E
They
only
describe
that
one
as
a
way
to
say:
I
want
to
go
and
load
entire
free,
but
don't
evaluate
it,
keep
it
there
and
only
when
I
access,
something
out
of
B
go
and
evaluate
that
thing.
So
we
describe
API
right.
B
A
Yes,
exactly
so,
let's,
let's
assume
that
import
sync
is
the
same
as
import.
Now,
the
the
the
existence
of
import
now
would
imply
that
you
can
already
execute
another
module
on
the
stack
provided
that
it
has
already
been
loaded.
A
B
Think
so,
okay,
so
therefore,
let's,
let's
assume
we
don't
have
import
now
or
import
sync
without
import
now
or
import
sync,
with
our
current
low
level
module
proposal.
Is
it
possible
to
do
the
scenario
that
I've
I've
outlined
where
a
determines,
what
capital
D
designates.
E
B
A
C
So
I
will
pass
along
that.
There's
concerns
about
re-entricity,
but
I
I
think
we'd
be
really
happy
with.
Like
a
specific.
You
know,
example
that
illustrates
the
problem.
Yeah.
A
Yeah
we
have
not
yet
found
yet
all
right
well,
we'll
keep
hunting
and
yeah
all
right
I'm
going
to
call
that
assess
meeting.
Thank
you.
Everyone.