►
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
Transpilers,
like
Babel
I,
haven't
taken
a
look
at
what
they
actually
do,
but
it
would
very
much
surprise
me
if
they
had
a
switch
such
that
they
were
acted
differently
depending
on
whether
they
considered
their
input
to
be
to
be
script
or
module
and
even
less
likely
is
for
them
to
pay
attention
to
whether
their
target
is
script
or
module
with
regard
to
whether
they
they
output,
HTML
comments.
So
for
all
of
these
reasons,
that
was
the
the
most
dangerous
thing
which
I'll
come
back
to,
but
we
all
we
all
agreed
to
stop
doing.
A
Optional,
syntax
that
has
that
problem:
okay,
so
yeah!
This
is
just
sort
of
a
general
orientation
about
all
of
the
reasons
why
things
end
up
in
annex
B
and
the
normative
statements
introducing
annex
B
of
that
it's
normative
a
normative
optional,
meaning
that
you
don't
have
to
implement
it,
but
he
do
implement
it.
You
have
to
implement
it.
This
way,
also
that
annex
B,
specifically
everything
there
was
considered
mandatory.
A
If
the
host
is
a
web
browser,
but
it
was
never
defined
what
it
means
to
be
a
web
browser
is
electron,
for
example,
a
web
browser
who
knows-
and
nobody
was
implementing
the
same
engine
to
operate
differently
with
regard
to
annex
B,
depending
on
whether
it
was
run,
for
example,
in
in
node
versus
being
run
in
a
browser.
So
so
a
lot
of
this
was
just
didn't
fit
reality
tremendously.
Well,.
A
Venn
diagram
of
different
distinctions
to
guide
us,
which
is
there's
Ekman
script
as
a
whole,
and
it's
got
we
sort
of
have
two
different
mechanisms
for
quarantine,
II
things
into
not
the
the
main
good
spec,
which
is,
we
can
put
things
into
annex
B
or
we
can
put
things
or
we
can
say,
the
things
are
sloppy
only
and
some
of
the
things
in
annex
B
are
also
things
that
are
stated
in.
Annex
B
are
sloppy
only
and
what
I'm
proposing
here
is
that
we
divide
we
consider
the
stuff
that's
in
annex
B.
A
That
is
not
sloppy.
Only.
We
divide
it
into
things
that
we
consider
to
be
safe
versus
things
that
we
consider
to
be
unsafe.
This
is,
with
regard
to
locality
of
causation
and
sort
of
normal
non
magic
conformance
to
object,
capability
rules
versus
strange
non-local,
causality
or
violations
like
the
ability
to
get
error
stacks
like
the
ability
to
create
weak
references.
Those
would
all
be
both
the
the
we'll
come
back.
Well,
not
the
weak
references.
Sorry,
the
error
stacks
thing,
the
part
of
that
that's
on
our
prototype,
dot,
stack
and
then
with
weak
references.
A
There's
this
political
controversy
around
one
particular
property,
but
basically
are
they
magic
that
introduces
potential
safety
violations
or
are
they
just
annoying
legacy?
That's
actually
perfectly
safe,
like
the
HTML
oriented
methods
in
string,
dot,
prototype
and
then
my
recommendation
is
that
of
the
safe
things
in
annex
B.
We
just
move
some
of
those
from
there
annex
B
status
into
the
main
stack
spec
as
mandatories.
A
Those
are
the
mandate
boxes
and
then
other
things
that
say
stay
is
they
stay
in
the
category
of
normative
optional,
and
that
was
all
that
I
was
prepared
to
recommend
when
the
talk
began
and
the
consensus
we
ended
up
with.
Is
that
the
normal
of
optional
things
actually
move
into
the
main
spec
just
very
clearly
marked
as
normative,
optional
and
I?
Think
that
actually
reads
much
better
and
n
Ehrenberg
has
started
some
PRS
to
do
that.
A
So
here's
a
complete
enumeration
of
all
the
things
in
annex
B,
so
the
things
that
I'm
proposing
to
mandate
that
are
simply
safe
in
the
upper
left
box
is
the
global
functions
escape
and
unescape
they're
not
recommended.
You
might
put
some
deprecated
language
around
them
for
all
the
good
that
that
does,
which
is
very
little
good,
but
any
case
they're
really
de
facto
required
by
all
implementations,
including
access,
so
you
might
as
well
just
put
them
in
the
main
spec.
A
One
would
think
that
maybe
the
purpose
of
that
was
so
that
by
omitting
them
you
could
have.
You
would
not
need
to
support
mutating
prototype
chains,
but
that's
not
true,
because
reflect
dot
set.
Prototype
of
is
not
normative.
Optional,
that's
mandated
in
the
main
spec,
so
the
dunder
proto
property
is
just
another
way
to
cause.
The
same
consequence
cause
the
same
effect
so
we're
not
in
accomplishing
anything
by
making
it
normative
optional.
The
worst
thing
is
the
dunder
proto
property
name
used
in
an
object.
A
Literal
does
so
that's
that's
clearly
very
bad
for
the
same
program
to
be
able
to
mean
two
different
things:
the
define
getter
defined,
Center,
look-up,
getter,
look-up,
setter
methods
on
underbar
prototype;
I'm.
Sorry,
when
an
object
that
prototype
are
really
best
defined
as
just
another
way
to
use,
get
on
property,
descriptor,
there's.
Basically,
it's
trivial
wrappers
on
get
on
property,
descriptor
or
define
property,
and
in
fact,
if
they
were
mandated.
A
Yes,
and
and-
and
the
fact
is
that
they
already
exist
everywhere-
they
were
already
documented
in
annex
B
so,
and
that
was
me
that
was
part
of
why
they
ended
up
in
annex
B
is
B
is
for
the
same
reason.
They
started
off
with
the
double
underbars
is
double
underbars
were
kind
of
saying
we're,
including
this,
but
we're
encouraging
people
not
to
use
it
or
some
kind
of
expression
of
distaste
and-
and
it
shouldn't
be.
A
You
know,
there's
enough
to
state
distasteful
things
that
are
in
the
main
spec
that
if
it's
really
required
everywhere-
and
we
don't
want
variation
in
program,
meaning
for
programs
that
are
not
statically
or
rejected,
then
we
should
just
graduate
it
to
the
main
spec
and-
and
if
we
want
to
to
continue
to
you
know,
to
have
language
that
says
that
they're
distasteful,
like
deprecated,
that's
fine,
but
it
doesn't
really
make
any
difference.
I.
B
A
B
So
here's,
where
I'm
kind
of
you
know
noticing
a
like,
like
that,
that's
probably
why
it's
been
annexed
right,
so
so,
but
but
if
you're,
if,
if
those
were
you
know
special
identifiers
and
they're,
not
obviously
you
you
know
they
are
valid.
I
identifiers,
but
it
just
goes
that,
like
you,
cannot
consider
them
like.
They
should
really
be
framed
in
such
a
way
that
people
using
them
are
very
discouraged
because
when
they
are
annex
a
lot
of
people,
don't
understand
why
they
are
in
Indiana
and
and
they
just
consider
them
not
in
favor.
B
A
So
I'm
not
I'm,
so
I'm
not
going
to
speak
about
to
the
to
the
issue
about
whether
we
deprecated
them
or
or
say
in
any
other
way
that
they're
to
be
avoided.
I'm
just
gonna
I'm,
just
gonna
talk
about
the
normative
distinctions
of
is
it
in
the
main
spec
or
not,
and
if
it's
in
the
main
spec,
is
it
normative
optional
or
not?
Also.
C
A
The
define,
getter
defined,
cetera,
lookup,
get
or
lookup
setter
is
just
another
way
of
doing
what
you
can
do
with
get
on
property
descriptor
and
define
property.
The
interesting
one
with
regard
to
semantics
to
avoid
is
the
dunder
proto,
but
since,
like
thoughts
that
prototype
of
is
already
mandated,
there's
there's
you
can
of.
You
can
suggest
to
people
not
modify
prototype
chains,
which
I
certainly
would
suggest
that,
but
that
suggestion
should
apply
equally
to
the
existing
documentation.
One
reflect
dot
set
prototype.
A
C
A
B
A
So
any
case,
the
the
string,
dot
prototype
methods,
the
extra
ones
that
we
ran
xB
are
harmless.
I'll
show
them
in
a
moment.
Likewise,
the
extra
methods
on
date
dot
prototype
with
regard
to
the
things
that
are
in
sloppy
mode.
There
were
also
an
annex
B.
The
fact
that
they're
in
sloppy
mode
to
my
mind,
is
adequate
quarantine.
They
don't
need
to
be
both
in
sloppy
mode
and
in
annex
B.
A
A
It's
got
bizarre
scoping
semantics
for
defining
a
named
function
inside
a
non
top-level
block,
whereas
in
strict
mode
defining
a
function
named
function
inside
and
on
top-level
block
has
straightforward,
lexical,
scoping
semantics
for
legacy
reasons
in
sloppy
mode.
It
has
bizarre
semantics
that
nobody
who
doesn't
implement
or
write
a
spec
can
possibly
remember
and
then
also
in
sloppy
mode.
You
can
use
functions
directly
as
branches
control
flow
branches
for
things
like
ifs
and
whiles
and
such
so.
A
Let's
just
go
ahead
and
mandate
all
of
those,
let's
just
really
really
shy
away
from
ever
making
syntactic
things
optional,
the
sloppy
mode
on
the
lower
right
that
stuff.
That's
currently
not
in
annex
B,
it
doesn't
appear
anywhere
in
the
spec
in
terms
of
the
sloppy
semantics
for
call
or
call
e
and
arguments,
but
at
least
all
the
browser's
feel
like
they
need
to
implement
them.
I
would
continue
to
have
them
listed.
I
mean
I
think
that
they
should
be
codified.
A
I'd
be
happy
to
leave
those
as
normative
optional,
rather
than
mandating
them,
but
because,
when
you
do
implement
them,
you
should
in
sloppy
mode
as
things
that
do
something
as
things
that
are
not
poisoned,
you
should
implement
them
to
have
their
expected,
meaning
that's
sort
of
the
purpose
for
which
we
have
normative
optional
and
then.
Finally,
the
upper
right
box
is
the
things
that
are
not
sloppy.
Only
that
I'm
recommending
remain
normative,
optional,
reg,
X,
dot,
prototype
dot,
compile.
A
Has
this
bizarre
semantics
that
actually
violates
us
the
frozen
invariants?
So
you
can
do
this
to
a
rake
X
instance
that
is
already
frozen.
Rekik
instances.
Do
you
have
one
own
property
index
or
something
and
compile
can
cause
that
property
to
change
state
even
on
a
frozen
reg
X
instance
Oh
last.
B
B
A
Certainly,
every
se
s
one
of
the
things
that
it
does
to
tame
its
environment
is
it
removes
reg,
X,
dot,
prototype,
compile
one
of
the
purposes
for
keeping
things
as
normative,
optional
and
deletable.
So
actually
there's
two
requirements
that
if
it's
present
it
B
deletable
and
that
it
that
that
you
can
conform
while
omitting
it,
and
that
means
that
a
startup
thing
like
SAS
can
can
delete
them
since
they're
deletable
and
then
having
deleted
them.
The
remaining
environment
is
itself
still
a
conforming
initial
JavaScript
environment.
So.
B
B
B
I
have
stayed
away
from
freezing
reg
X
objects
because
you
know,
like
I've,
noticed.
Dom
elements
have
this
like?
Okay,
you
can
freeze
me,
but,
like
you
know,
doesn't
really
do
anything
right,
so
so
I'm
just
worried
that,
because
last
index
is
updated,
you
know
I
believe
it
actually
throws
and
they're
like
I,
have
to
test
I'm
gonna
document
in
for
next.
You
know
yeah.
A
What
we
should,
if
there's
an
issue
there
and
if
there's
an
issue
there,
we
can't
get
everybody
to
agree,
don't
mutate
the
last
index,
then
what
we
should
do
instead
is
make
last
index
and
access
or
property
instead
of
the
data
property,
and
maybe
even
have
it
be
an
access
or
property.
That's
on
reg
X
prototype
so
that
it
gets
inherited
and
then
the
last
index
state
would
then
be
on
an
internal
slot
and
it
doesn't
violate
anything
from
internal
slot
to
get
mutated
on
a
frozen
object.
Yeah.
A
B
Frozen
doesn't
change
length,
so
length
will
always
be
constant,
even
if
it's
not
like
actually
unsettle
on
any
level
like.
It
still
remains
that,
had
this
array
been
not
frozen,
the
length
would
have
changed
and
the
runtime
might
have
given
a
different
value
for
length,
but
it
doesn't
rate,
but
that
is
before
last
index.
So.
A
A
The
other
thing-
that's
that's
here:
that's
in
na
currently
mannix
B
is
document
dot.
All
is
this
incredibly
bizarre
legacy
thing
for
which
the
spec
very
very
clearly
says.
There
is
only
this
one
special
case
of
this
odd
behavior,
where
for
some
purposes
some
purposes
that
acts
like
an
object
and
for
other
purposes
that
acts
like
undefined.
A
It's
like
a
complete
violation
of
JavaScript
semantics,
as
normally
understood,
and
we
will
continue
to
say
that
it
should
only
be
implemented
by
browsers,
and
it
should
only
be
implemented
for
this
one
particular
property
time,
but
you
should
go
ahead
and
move
it
into
the
main
spec
as
a
normative
optional
with
all
of
those
qualifiers.
This
document.
A
A
A
A
Ability
for
it
to
recognize
an
initializer,
so
you
can
say
VAR
x,
equals
y
in
and
four
for
in
having
an
initializer.
There
makes
no
sense,
but
somebody
wanted
the
browser
we
at
one
point
the
spec
tried
to
remove
it.
One
of
the
browser's
tried
implementing
it
found
that
there
is
still
too
many
sites
that
broke,
even
though
it's
completely
useless
and
meaningless
syntactic
construction.
So
it
came
back
in
I.
Don't
remember
if
that's
sloppy,
only
or
not
I,
remember
one
of
them.
A
One
of
these
two
things
that
I
have
there
turned
out
to
be
sloppy.
Only
it
was
less
than
a
shoe
that
I
was
worried
about
the
other.
One
is
inside
a
catch
block.
If
there
is
a
VAR
declaration
inside
the
block
that
looks
like
it's
shadowing
the
catch
variable,
there's
something
that's
normative
optional
about
whether
that's
an
error
or
not
and
I
know
you
remember,
which
way
it
goes.
A
A
But,
but
both
of
those
have
the
feature
that
having
the
syntax
normative
optional
does
not
enable
one
program
text
to
mean
two
different
things,
because
in
the
other
interpretation,
where
it's
not
where
it
is
or
is
not
recognized,
the
behavior
would
be
a
static
error.
I'm
gonna,
have
it
having
optional
syntax,
where
one
alternative
is
that
you
have
a
working
program
and
the
other
alternative
is
that
you
have
a
static
error.
That's
much
less
damaging
I'm.
B
A
There
was
not
I,
don't
remember
anybody
discussing
it.
I
know
that
it
was
considered
when
this
was
originally
happening
and
I
think
the
let
case
is
not
problematic,
because
that
won't
because
let's
do
not
waste
out
of
blocks.
Therefore,
my
suspicion
is
that
that
means
it
just
shadows
without
a
problem.
But
that's
under
an
assumption
about
what
the
scope
of
the
catch
variable
is.
So
you
would
need
to
double
check
that
I
have
to
admit
that
on
these
issues,
I
just
listed
them
for
completeness
and
so
that
we
could
make
a
determination.
A
I'll
come
to
HTML
comments
last
so
the
Reg
X
dot
star.
Those
are
the
weird
reg
X
statics
that
are
currently
proposed:
they're,
not
two
before
and
xB
they're,
not
yet
they've
not
yet
made
it
all
the
way
through
the
standards
process,
but
they
universally
implemented
they're
not
currently
universally
implemented
correctly,
because
on
one
of
the
browsers
I
think
Firefox
they're,
not
actually
deletable.
So
SES
has
to
do
something
bizarre
to
effectively
delete
them
anyway,
which
we
do,
but
in
any
case
they
they
will
become
standard.
A
A
So
what
SAS
will
do
is
to
remove
the
behavior
of
error,
prototype
stack
and
only
use
the
get
stack
and
get
stacks
of
string
system
e
things,
and
so
and
there's
a
similar
issue
with
specifically
the
property
we
craft,
dot
prototype
dot
constructor,
which
is
we
do
not.
We
want
it
to
be
the
case
that
I
can
give
I
can
give
out
a
tweak
ref
instance.
That's
a
weak
ref
give
that
to
some
code
such
that
it
can
now
observe
whether
that
particular
thing
gets
garbage
collected
without
enabling
that
code
to
create
other.
A
We
graphs
that
enable
it
to
observe
whether
other
things
get
garbage
collected
and
the
only
thing
that
stands
in
the
way
of
that
is
this
one
property,
except
with
this
property,
there's
no
way
to
navigate
from
a
weak
ref
instance
to
a
recraft
constructor,
and
there
is
existing
precedent
in
the
spec
for
not
having
a
constructor
property
on
the
prototype.
So,
for
example,
the
map
iterator
prototype
does
not
have
a
her
property,
does
not
have
its
own
constructor
property
and
if
you
say
on
a
map,
iterator
got
constructor.
B
A
But
yes,
if
we
didn't
have
agreement
for
the
constructor
property
could
be
optional,
then
we
would
have
to
work
around
it
in
that
way,
and
we
should
support
working
around
that
in
a
standardized
way,
which
is
a
lot
more
added
complexity
than
just
omitting
the
constructor
property.
My
preference
would
be
that
we
don't
make
it
a
normative
optional,
but
rather
we
just
omit
it
and
we
mandate
that
it
be
omitted,
but
I'm
failing
to
get
consensus
on
that
and
then.
A
Finally,
there
is
the
most
ugly
thing,
which
is
the
HTML
like
comments,
and
the
problem
is
that
when
they're
not
recognized
as
syntax,
they
can
be
a
valid
operator,
sequence,
they'll,
operand
less
than
the
negation
of
the
pre-decrement
or
something
or
something
or
operand.
Post
decrement
is
greater
than
something.
A
So
you
can
write
programs
that
change
their
meaning,
so
we
got
consent.
So,
even
though,
all
of
us
hate
this
thing
in
wish,
we
could
avoid
it.
We
know
that
we
can't
the
normative
optional
is
even
worse
than
mandating
something
we
hate
everywhere.
So
we
got
agreement
and
committee
to
simply
mandate
this
for
scripts,
both
strict
and
sloppy,
and
then
there
is
an
additional
issue
that
was
mentioned
that
I
raised
in
my
presentation.
I
made
a
recommendation.
C
Shorts
there
get
the
transpiler
comments,
so
I
can
short-circuit
some
of
the
transpiler
discussion.
That
would
be
useful.
The
main
parsers
yes,
prima
Babylon
typescript
and
also
acorn
all
have
a
input
flag.
Most
are
now
requiring
you
to
declare
if
the
source
texture
parsing
is
supposed
to
be
a
script
or
a
module
and
inside
the
module
flagged
format.
They
do
not
support
HTML
comments
for
quite
a
while,
but
if
you
go
back
far
enough,
I
know
babble
does
I.
Think
it's
like
four
years
ago.
C
A
C
A
And
since
since
HTML,
like
comments
enable
a
program
to
mean
two
different
things,
you
could
in
fact
write
a
program
that,
if
HTML
comments
are
recognized,
the
program
is
consistently
recognized
as
a
script
and,
if
HTML
like
and
you
know,
for
example,
it
does
not
contain
an
import
or
export
statement.
And
if
HTML
like
comments
are
not
recognized,
then
it
does
contain
an
import
or
export
statement
so
that
recognizing
it
either
as
a
script
or
as
a
module
would
both
be
a
consistent
story.
And
of
course
you
can
do
the
opposite.
A
So
you
have
a
paradox,
which
is:
if
it's
a
script,
it's
a
module
and
if
it's
a
module,
it's
a
script.
So
so
so
any
kind
of
self
detection
is
really
quite
quite
disastrous
here.
What
I
recommended,
which
I
still
prefer,
and
what
SAS
currently
does,
is
that
if
they
are
detected,
then
the
program
is
statically
rejected.
A
So
instead
of
worrying
about
well,
what
should
the
program
mean
if
these
things
appear,
if
they
appear
just
statically,
reject
the
program,
say
if
I'm
not
confident
that
I
can
interpret
this
program
to
mean
what
the
programmer
intended
it
to
mean?
That
I'm
doing
the
program
or
a
favor
by
just
rejecting
the
program.
A
B
Before
the
bubbles,
sorry
back
to
comments,
one
second,
because
I
was
really
trying
to
make
sense
of
what
the
spec
of
the
annex
be
going.
The
annex
part
was
was
really
describing
that
this
should
parts
as
and
I
was
having
a
lot
of
difficulty
with
the
language
as
to
whether
or
not
they
were
saying
that,
if
it
overlapped
with
a
more
two
line,
comment
that
one
of
them
can
begin
where
the
other
you
know
they
they're
not
encapsulating
one
another.
B
It's
not
like
the
beginning
of
a
comment
could
be
the
multi
line
and
the
end
of
it
could
be
the
HTML
like
end
early.
There
was
a
very,
very
weird
thing
happening
there
that
you
know
for
annex
B.
You
know
they
just
say
that
you
know
we're
putting
it
so
people
would
not
be
surprised
if
it
happened,
but.
B
A
A
One
of
the
things
that
I
did
in
introducing
the
topic
at
tc39
is
I
took
my
first
started
with
the
poll
of
the
room.
I
said
everyone
here
who
has
worked
on
a
conforming
JavaScript
parser.
Please
raise
your
hand
and
this
paint
ac30
light.
A
lot
of
hands
went
up.
A
lot
of
hands
did
not
go
up.
I'm,
not
I,
said
okay,
everybody
who
just
raised
your
hand,
keep
your
hand
down
for
the
next
poll
for
everyone
else.
A
If
you
think
you
know
precisely
what
the
parsing
rules
are
for
HTML
like
comments,
please
raise
your
hand
and
one
hand
went
up
which
is
Aki
and
Aki
explained
that
Leo
Balter,
who
had
had
just
explained
to
her
in
some
detail
about
this,
and
otherwise
she
she
would
not
have
known
so
so.
Essentially,
nobody
who
does
not
work
on
a
parser
you
what
the
rules
are
for
this
thing
anyway,.
B
Yeah,
if
it's
mandated
I,
definitely
hope
that
you
know
someone
with
a
bit
of
knowledge.
I
believe
I
do
qualify,
would
be
able
to
make
sense
of
what
they're
really
indicating
because
like
if
it's
just
gonna
be
moved
over
I
think
that
would
be
problematic.
B
A
A
A
A
How
worried
we
should
be
anyway,
but
in
any
case,
they're
universally
implemented,
likewise
to
GMT
string
and
then
the
Reg
X
that
the
Reg
X
static
properties
are
all
of
this
weird
non-local
global
communication
danger
static
properties
that
are
just
information
about
the
last
reg
X
instance
match
that
happened
for
any
reg
X
instance
in
this
realm.
Yeah
just
think.
A
A
So
so
SES
car
has
always
just
deleted
them
and
we've
actually
never
run
across
a
program
that
broke
because
we
deleted
them.
But
there's,
but
you
know,
our
tolerance
for
breaking.
Programs
is
much
higher
than
the
tolerance
of
the
browser
manufacturers,
ferment
for
breaking
programs
and
for
very
good
reason.
So
that's
why
we
put
it
as
normative,
optional.
C
A
B
I
guess
it's
a
good
opportunity
with
three
of
us
to
just
talk
about
thrusted
fights
at
some
point
in
this
meeting.
I'm
just
gonna
have
to
run
out
for
a
couple
of
minutes
and
I'll
be
back.
If
you
guys
don't
want
okay,
okay,.
C
Sure
so
mark
well
I've
got
you
here
from
a
minute.
I
spent
most
of
my
paternity
leave,
trying
to
figure
out
a
good
way
to
allow
garbage
collection
within
a
single
realm
of
modules
and
I.
Just
can't
see
any
feasible
way
to
do
that.
With
the
current
language
semantics
we've
got
four
JavaScript
so
for
now,
you're.
C
Whenever
we're
gonna
go
through
with
this,
we're
probably
going
to
end
up
having
to
just
say
that
the
lifetime
of
a
module
is
tied
to
the
realm
which
created
it
all.
Forts
that
allow
distributed
collection
require
deep
garbage,
collector
garbage
collection
cooperation,
which
we
don't
get
enough
of
from
weak
refs,
because
we
don't
want
to
expose
them.
Privy
information
so
and.
A
C
C
For
now,
I
think
just
going
forward,
at
least
for
our
first
ship
shippable
product,
we're
gonna,
have
to
just
say
the
lifetime
of
a
module
is
that
of
the
realm
which
created
it
and
we're
going
to
have
to
go
down
a
route
of
looking
at
how
we
can
make
mini,
realms
and
coordinate
deletion
of
realms
to
free
up
space.
So.
A
So
I
don't
understand
how
that
would
meet
the
constraints,
because
you
can
have
multiple
root
realms
that
are
part
of
one
shared
object
graph
under
one
garbage
collector.
In
fact,
you
need
you
in
the
browser.
This
comes
up
with
the
same
origin
iframes,
so
it
would.
It
would
seem
like
the
constraint
you're
talking
about
where
the
cycle
comes
up
between
garbage
collectors.
A
So,
what's?
Okay,
so
you
so
you've
got
one
object.
Graph
you've
got
root
realm
a
and
root
realm
D
and
root
round.
B
has
loaded
module.
M
is
of
the
shared
object.
Graph
module
M
is
reachable
from
objects
that
were
born
as
part
of
root
realm
a
and
then
root
realm
B
is
otherwise
garbage,
but
a
still
holds
on
to
n
yep.
A
Cause
I
mean
it?
Does
it
didn't
matter
that
that
root
realm
B
was
otherwise
garbage
as
long
as
a
is
holding
on
to
it
its
held
on
to,
and
then,
if
the
thing
in
a
that's
holding
on
to
it
is
itself
only
how
is
only
non
garbage,
because
it's
part
of
an
external
cycle
that
still
pins
the
mantra
still
doesn't
allow
you
to
garnishment
the
module.
C
C
C
A
A
Because
so,
actually,
so
something
I'm,
not
understanding
here
within
an
import
namespace
within.
What's
you
know
what
we've
been
thinking
of
as
there
are
the
loader
or
the
registry
of
a
loader
or
something
there's
already
a
canonical
mapping
from
something
like
a
module
specifier
some
kind
of
meal
resolved
specifier
that
canonical
mapping
of
that
to
a
module
instance
and
a
module
instance
potentially
has
mutable
state.
That
uniquely
happens
for
that
instance
on
initialization.
A
So
I
already
don't
see
how
it
would
seem
to
me
that
once
an
instance
has
been
loaded
into
a
registry
has
been
registered
in
a
registry
under
some
kind
of
global
specifier
that
as
long
as
that,
global
specifier
could
be
regenerated,
that
the
same
instance
would
have
to
be
reproduced,
and
therefore
the
registry
would
already,
even
without
this,
this
inter
agent
cycle,
that
the
registry
would
already
have
to
retain
all
module
instances
that
that
it
ever
instantiate.
Is
that
not
the
case
that
is.
C
C
A
A
C
B
C
A
A
C
A
A
C
A
B
C
So
there
are
two
situations
here:
there's
one:
if
the
module
is
stored
in
the
global
module
map,
re-importing
it
somehow
later
would
always
give
you
the
original
instance,
because
the
module
map
keeps
it
alive
forever.
It
can't
be
garbage
collected.
The
other
is
for
ideas
like
VM
module,
those
the
unforgeable
x'
we're
talking
about
the
MDOT
module.
C
B
Obviously,
if
it's
garbage
collected,
that's
one
thing,
but
I
mean
if
it
if
it
could
be
allowed
to
be
carbage
collected
if
it
was
the
side-effect
of
somewhere,
you
importing
a
string
and
whatever
mechanisms
were
in
the
middle
led
led
that
stream
in
that
realm,
to
import
the
particular
module
dynamically
importing
the
same
string
after
all,
references
were
gone,
regardless
of
how
you
give
the
illusion
of
a
module
or
actually
implemented,
should
not
resolve
in
top
level
execution
and
in
recreation
of
all
the
you
know
of
anything
you
know.
For
that
specific,
you
are
out.
C
C
That
has
a
different
module
map
from
the
realms
module
map.
That's
the
local
module
map,
as
mandated
by
the
spec.
So
once
you
import
into
a
source
text,
module
record
something
you
are
required
that
that
reference
to
that
specifier
always
point
to
be
resolved,
module
reference.
So
if
you
import
something,
it
cannot
be
garbage
collected
in
the
same
source
text
record.
So
this
isn't
it's
not
possible
for
you
to
so
for.
B
Gc,
so
what
I
was
thinking
here,
Rather's
round
beings?
You
know
within
that
behavior
happening.
You
know
you
know
above
it
on
a
on
a
grander
level.
Then
you
would
expect
that
behavior
to
hold
within
a
realm
as
well
that
arounds
dynamic
imports
of
the
same
string,
regardless
of
how
it
relates
to
the
containment
process.
Within
the
you
know,
parent
or
the
route
module
map
behaviors.
C
One
is
you
make
an
import
map,
you
let's
say:
import
map
is
to
HTTP
example.com
/foo,
and
you
have
two
modules
that
the
thing
is
importing
two
different
scopes.
They
are
both
overwriting
example.com,
slash
bar
the
full
URL
to
point
to
different
absolute
URLs,
and
so
you
could
import
example.com
bar
in
one
module,
have
it
deleted
and
then
in
a
different
source
text,
module
record
import,
example.com,
slash
bar
and
get
a
different
module
record,
resulting
in
new
instantiation
and
evaluation.
B
B
So
it's
like
it's
really
only
out
in
the
world,
for
maybe,
if
they're
like
origin
based
rollouts
I'm,
not
sure,
but
for
me
it
gives
an
error
if
I'm
not
shadowing,
for
a
built
in
like
using
a
custom
URL
that
falls
back
on
one
of
the
built-ins
and
then
I'm
allowed
to
actually
fall
back
on
on
a
on
a
polyfilled
which
really
doesn't
work
for
other
browsers,
because
they
don't
support
that
now,
so
so
import
not
Maps
has
a
lot
of
like.
If
we
get
there,
then
we
can
figure
out
all
these
problems.
C
B
B
I'm
not
sure,
like
I've,
never
had
a
point
where
I
could
prove
it
like
I
didn't
go,
try
to
disprove
it
or
prove
it,
but
it's
been.
You
know
it's
been
kind
of
like
the
the
principle
behind
you
not
really
deciding
what
the
but
the
blog,
you
know,
suffix
or
the
blog
number
is
or
whatever
they
call.
That
is
that
they're
trying
so
hard
to
make
sure
that
you
tell
the
blob
what
it
will
have
and
then
it
will
tell
you
what
it
will
be.
B
B
B
If
the
module
results
in
records
somewhere,
when
it's
evaluated,
like
the
top
level
code
of
the
module,
somehow
affects
your
state,
you
know
the
state
of
things
not
just
atmospheric
point,
for
which
ACMA
script
is
an
interface.
Then
we
running
that
code
again
because
you
garbage
collected
the
first
instance
you
know
and
in
the
context
upon
which
the
echo
spirit
realm
operates.
Or
you
know
it
is
an.
C
B
B
So
so,
if
it's
not,
if
it's
not,
it's
not
made
concretely
restricted
that
is
bringing
in
a
dynamic
import
should
never
result
in
a
recreation
or
anything
in
a
dynamic
import
should
actually
be
garbage
collected.
More
then,
we're
really
creating
this
opportunity.
Burg,
unpredictable
behavior
from
very
predictable
code,
more.
C
C
B
So
so
yeah
I
guess:
yes,
you
know
we're
trying
to
clarify
from
two
different
from
two
opposite
pens
or
two
different
perspectives
on
a
problem.
I
guess
implementation
wise
if
it
if
it
creates
a
problem,
we'll
be
able
to
maybe
have
a
better
like
a
more
productive
or
a
more
constructive
way
to
look
at
it
for
now.
I
think
you
know
we
try.
A
A
A
So
actually,
I'm
going
to
do
this,
not
sequentially,
because
the
most
interesting
thing
was
a
academic
that
those
research
on
programmers
psychology
and
how
people
interact
with
programming
languages.
Here
we
go,
fell,
lien,
Herman's,
evidence-based
programming,
language
design,
Julia
invited
her
you'll.
You
did
a
presentation
immediately
afterwards
on
her
own
work.
That's
on
probing
some
JavaScript
issues
that
are
very
much
in
line
with
that
academic
framework
and
I
thought.
All
of
that
was
just
fascinating
and
I
really
like
the
way
in
which
that's
being
brought
into
our
discussion.
A
But
at
the
same
time,
it
is
additional
evidence
to
take
into
account
and
addition
of
new
syntax
should,
in
general,
need
to
pass
a
very
high
bar
on
reasons
to
accept
it.
So
evidence
along
experimental
evidence
along
these
lines
could
be
a
significant
contributor
in
an
argument
about
whether
or
not
to
add
new
syntax.
The
particular.
A
A
You
know
you
learned
a
lot
more
about
how
to
go
about
this
in
order
to
create
valuable
experiments
that
do
give
us
valuable
information,
but
this
one
itself
should
not
be
interpreted
as
having
given
us
valuable
information
about
the
pipe
syntax
itself.
Okay,
now,
let's
go
back
sequentially,
so
mike
samuel
presented
several
things
that
fit
together
that
leader
first
supportive
of
the
trusted
types
thing,
but
trusted
types,
oh
and
and
oh,
and
he
did
present
on
trusted
types
I'm,
seeing
with
slides,
but
trusted
types
are
not
being
proposed
to
tc39.
A
So
is
more
of
a
background
and
the
other
things
that
are
supportive
of
it
are
being
proposed.
So
eval
of
an
on
string,
the
current
eval
spec
says
that
if
you
apply
eval
to
anything
other
than
a
string,
it
just
acts
as
the
identity
function.
It
doesn't
evaluate
anything
and
it
just
returns
that
thing
and
what
mike
wants
to
do
with
trusted
types
is
to
enable
some
kind
of
branding
of
a
string
wrapper
such
that
in
an
environment
in
which
evaluation
is
otherwise
suppressed.
A
Next,
one,
the
resolve
property
for
promise
all
was
just
making
it
more
consistent
with
other
things
in
the
spec.
In
order
to
support
efficiency
without
penalty,
what
all
errors
be?
Syntax
errors
for
for
unmotivated
reason.
There
were
some
early
errors
for
some
syntactic
cases
that,
through
reference
error,
rather
than
syntax
errors,
we
all
agreed
that
those
should
all
be
syntax
errors,
I.
A
A
A
Dynamic
import
that
I
at
the
previous
meeting
I
had
asked,
and
the
committee
had
granted
to
postpone
the
issue
until
the
last
meeting,
so
that
I
could
discuss
it
and
with
at
the
SES
meeting,
which
we
did
so
at
the
last
SES
meeting,
where
I
brought
it
up,
we
decided
we
did
not
need
to
hold
back
or
dynamic
import.
So
if
this
last
meeting
dynamic
import
did
make
it
to
stage
four,
so
it's
basically
it
is
now
done.
A
B
Michael
fig
yesterday
in
so
I
raised
the
point
about
specter
in
shared
array
buffer
and
the
fact
that
it
relied
on
the
fact
that
it
can
very
quickly
know
across
more
than
one
context
stuff
through
a
shared
array
buffer.
If
solving
the
problem
hysterically
by
you
know
demoting
progress
of
shared
array
buffer,
where
it
could
have
been
solved
by
adding
latency
to
Atomics.
B
A
Can't
be
solved
with
adding
latency
to
Atomics.
The
problem
is
that
you
can
use
shared
array
buffer
in
a
racy
manner
where
there's
no
guarantees,
but
the
way
it's
actually
implemented
universally
is
such
that
without
any
atomic
operations,
you
just
have
one
thread:
just
looping
indexing,
I'm,
sorry,
incrementing
looping
in
incrementing,
one
location
in
memory
and
then
in
the
other
thread
you
keep
sampling
it.
You
now
have
an
incredibly
high
resolution,
timer
it's
outside
the
spec,
because
it's
racing,
the
spec,
doesn't
guarantee
anything.
A
B
A
Regress
made
it
to
stage
three
that
was
also
one
where
I
had
held
it
back
on
the
previous
meeting
because
of
the
issue
of
name
space.
Where
did
the
names
get
stack
and
get
stacks
or
get
stack
string
up
here?
They
cannot
appear
on.
You
know
on
something
reachable
from
standard
Global's,
because
then
you
cannot
virtualize
them
in
a
differential
manner
between
different
compartments
inside
the
same
route
route
might
propose
them
on
the
system
object.
There
are
objections.
The
system
object
as
so.
A
A
So
there's
the
global
object
is
not
going
to
be
one
that
continues
to
grow
more
Global's
as
specified
as
part
of
standard
JavaScript,
but
we're
going
to
try
to
move
future
growth
into
growth
of
built-in
modules
that
a
secure
environment
like
SAS,
can
simply
know
about
dangerous
new
Global's
like
get
stack
and
get
stack
string
as
special
cases
and
just
MIT
them
from
the
whitelist
and
then
move
the
real
attention
to
namespace
quarantine
into
the
management
of
the
namespace
for
built
in
modules.
I'll
get
back
to
built
in
modules.
A
Promise
dot
race,
it's
dual
is
promise
that
all
settled
promise
dot
any
is
the
proper
dual
to
promise
dot
all,
and
if
nobody
wants
to
dive
into
that
I'll
just
leave
it
there.
It's
all
documented,
very
clearly
and
there's
there's
just
just
you
filling
things
out
for
uniformity,
for
an
enumeration
order
from
the
title
of
the
proposal,
I
had
hoped
that
Kevin
was
going
to
Kevin.
Gibbons
was
going
to
bring
us
to
agreement
on
an
actual
deterministic
spec.
But
no
such
luck-
we
still
are
not
where
we
can
get
Universal
consensus
on.
A
A
And
the
so
there
was
a
big
political
fight
where
the
w3c
is
yet
again
trying
to
blur
the
lines
between
JavaScript
and
host
kind
of,
under
the
belief
that
that
the
browser
is
the
only
host
that
matters
and
not
understanding
or
not.
Appreciating
that
the
JavaScript
versus
host
separation
is
why
javascript
versus
host
is,
is
such
a
good
analogue
of
user
mode
versus
system
mode?
So
we
had
a
big
fight
about
that
and
it's
you
need
to
go
forward
with
a
a
JavaScript,
specific
namespace.
A
Then,
with
regard
to
reserving
other
top-level
names
it,
we
need
to
be
aware
of
the
political
issues
that
always
come
when
you
try
to
centrally
administer
a
human
readable
namespace
in
an
open
world
might
accidentally
end
up
reproducing
all
the
political
problems
that
the
ICANN
had
trying
to
administer.
The
top-level
namespace
I.
B
On
this
particular
topic,
there's
a
very
disturbing
thread
in
which
the
pressure
was
made
on
jdd
to
give
up
his
npm
STD
namespace
in
order
for
STD
to
become
the
standard,
JavaScript
namespace,
and
when
you
read
a
thread
like
this
involving
people
involved
with
the
specs,
you
kind
of
like,
like
I,
initially
thought
him
having
STD
e,
as
you
know,
STD
slushees,
and
that
that
was
cool.
But
when
I
saw
this
thread
and
I
saw
that
you
know,
there's
a
proposal
being
presented
that
builds
off
of
like
the
very
gracious
you
know
upon
pressure.
B
B
A
The
issue
with
with
some
with
identifier
:
as
a
prefix
is
then
these
things
look
like
URLs
on
your
namespace
they're
already
accepts
URLs
and
so
proposal
that
had
been
made
on
an
issue
thread
somewhere.
That
I,
don't
remember
if
it
was
explicitly
mentioned
during
the
meeting,
is
that
any
such
prefix
actually
get
registered
with
the
with
the
IAEA
or
where
everyone
registers,
URI
prefixes
protocols,
hang.
B
On
thank
you
because
that's
what
I
recommend
it
to
know
that
about
nodejs
:
and
they
were
like
module
modules
test
fires
are
not
URLs.
Oh,
you
know.
This
debate
is
killed
if
you're
going
to
have
force
people
to
use
file.
:,
so
don't
tell
me
it's
not
module.
You
are
else
just
because
you're
afraid
to
put
it
in
this
pack,
and
you
keep
coming
to
the
point
that
you
want
to
use
identifier,
:
and
many
things
around
them.
Yeah
yeah.
A
And
there-
and
there
already
is
a
governance
procedure-
that
the
world
accepts,
the
NA
I
think
that's
the
one
that
one
registers
URI
protocol
names
with.
So
yes,
I
think
we
should
just
delegate
to
them
the
governance
of
the
introduction
of
new
protocol
names.
It
would
be
very
good
for
the
JavaScript
standard
library
to
be
je
s.
:
I,
don't
know
if
it's
still
available,
yeah.
B
B
But
if
you
are
going
to
have
browsers,
you
have
standard
libraries,
then
then
it's
going
to
be
problematic
for
them
to
find
such
a
thing
that
they
can
register
and
agree
on
very,
very
difficult,
because
you
you
throw
if
you
import
something
that
is
not
known
by
the
platform
and
if
you
are
importing
a
built-in
of
a
browser
by
running
a
module
in
a
browser
that
you
don't
yet
know
what
it
is,
then
it
being
different.
A
different
prefix
for
the
huge
browser
is
going
to
be
very
problematic
and
I.
B
A
B
A
So
I
think
what
people
were
proposing
if
the
if
the
w3c
ends
up
occupying
namespace
for
the
browser
as
a
host
is
I,
think
people
were
thinking
of
web
Cohen,
oh,
but
but
the
other
thing
that
I
feel
strongly
about
is
just
the
JavaScript
namespace
and
then
as
much
as
possible
us
not
creating
a
new
worldwide
governance
procedure
for
administering
top-level
names
of
the
namespace.
The
world
does
not
need
new
politics
like
that.
B
Definitely,
and
thank
you
so
much
for
being
very,
very
to-the-point
with
them,
because
I've
tried
to
raise
concerns
in
that
realm,
like
in
this
area
of
the
discussions,
and
it's
very
hard
to
argue
when
people
tell
you
well
modules.
Classifiers
are
not
URLs
well,
just
because
you
write
stuff
in
this
pack,
and
you
have
that
privilege,
it
doesn't
mean
that
you
could
argue
at
me
what
is
actually
very
false.
We
all
use
module
specifiers
as
URLs.