►
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
Oh
all
right,
awesome,
daniel,
take
it
away.
B
Great,
so
there
were
two
questions
that
we
discussed
previously
with
how
records
and
temples
would
interact
with
the
read,
only
collections
proposal,
and
I
think
we
have
a.
We
have
a
shared
interest
in
making
sure
these
work
well
together
and
not
not
overlap
in
harmful
ways.
B
The
first
one
was
raised
by
model
about
so
I
think
I
wanna
the
risk
of
putting
multiple
people
on
the
spot
if
they
to
present
their
their
concern
with
the
the
lack
of
of
benefit
of
going
with
something
sort
of
new.
That's
not
objects.
So
you
can
explain
that
the
second
concern
was
raised
by
mark
about
if
we
want
to
make
a
box
explicit,
because
that
could
lead
to
a
mismatch
versus
the
the
potential
output
of
the
snapshot
method,
if
that's
upgraded
to
records
and
temples.
B
C
Thanks
dan,
I
I
would
say
I
mean
I
will
try
to
be
brief
and
we
can
we
can
discuss.
I
won't.
I
don't
want
to
hold
the
floor
for
too
long.
I
think
arkans.
So,
first,
we
use
frozen
deeply
frozen
objects
all
the
time
like
we're
a
heavy
user
of
them,
and
we
are
like
our
entire
engine
and
all
the
products
we
build
with
it
depend
on
on
frozen
objects.
C
So
we
think
it's
spectacular
that
the
committee
is
spending
time
on
how
that
should
be
handled
in
the
language
like,
so
so
we're
we're
totally
on
board
with
the
big
scale
of
the
direction.
C
The
the
concern
that
we
have
is
that
it's
a
very
it's
a
piecemeal
approach
and
in
fact
that
what
what
what
records
and
tuples
I
will
try
that
pronunciation
today,
records
and
tuples
do
is
bolt
on
a
solution
for
immutability
to
the
side
of
the
language,
creating
a
separate,
very
similar,
parallel
universe
to
what
already
nearly
exists
with
frozen
objects,
and
we
don't.
We
would
like
to
see
a
solution
that
works
for
the
language,
as
it
exists
today,
more
much
more
than
something
that's
bolted.
C
On
the
side,
and
so
the
the
place
where
that
that
issue
first
became
clear,
is
on
the
collections
topic
dan,
which
you
which
you
raise.
So
I
will.
I
will
pause
there
because
I
think
that's
at
least
a
summary
of
where
we
are,
and
I
I
we
should
probably
talk
from
there.
C
Sorry
so
I
I
I
apologize
if,
if
my
choice
of
words
suggested
that
the
quality
of
the
proposal
is
lacking,
it's
not
it's
excellent.
It's
incredibly
well
thought
out.
It's
incredibly
well
documented,
but
it
is
a
new
set
of
primitives
in
the
language.
C
It's
new
objects
and
it's
very
hard
to
explain
to
somebody
who's,
not
deep
in
the
in
the
language
design,
space
about
why
a
record.
Why
and
how
a
record
is
different
from
an
object
and
why
that
should
be,
and
and
especially
when
we
already
have
frozen
objects
which
behave
not
exactly
the
same
as
records.
C
I
understand,
but
but
not
all
that
differently
either
and
so
we're
we're
in
some
ways
like
deprecating
or
confusing
frozen
by
adding
records,
and
yet
we
still
have
other
many
objects
in
the
system
which
can't
be
made
immutable
by
either
mechanism,
and
so
it's
it's
it's
it's
adding
significant
complexity
and
that
by
by
basically
creating
a
variation
of
two
existing
objects,
rather
than
increasing
the
consistency
in
the
in
the
language
by
addressing
immutably
more
holistically.
So
I
apologize.
I
I
my
choice
of
words
was
poor
and
it
didn't.
D
E
Can
I
ask
a
clarification
question
please
about
what
peter
just
said,
so
we
were
under
the
information
the
champion
group
of
the
proposal
that
there
was
implementability
issues
with
the
proposal,
but,
as
I
understand
peter
and
correct
me,
if
I'm
wrong,
you're
saying
that
it's
more
about
inner
complexity
added
to
the
language,
but
not
necessarily
linked
to
implementation
complexity,.
C
There
may
or
may
not
be
implementation
complexity.
Okay,
we
are
not
we're
not
far
enough
down
that
road.
That
said,
we
have
done
significant
work
in
implementing
immutability
across
the
javascript
language,
so
we
do
have
some
sense
of
what's
involved
there
and
it
wasn't.
It
wasn't
a
small
project
to
make
that
work.
E
Okay,
yeah,
that
makes
sense
so
so
right
now,
the
main
concern
is
about.
This
is
inducing
more
complexity
in
the
language.
B
B
One
of
the
one
of
the
big
qualities
of
records
and
temples
is
this
deep
structural
equality,
or
at
least
shallow
value
equality,
at
least
that
they're
compared
by
value
by
the
by
the
immediate
contents,
and
then
that
maybe
applies
recursively
if
it
also
contains
other
templates.
So
I'm
wondering
if
we
could
brainstorm
ways
that
we
could
provide
this
kind
of
you
know
recursive
equality
definition
without
you
know
well
being
consistent
with
the
rest
of
the
language.
C
Sure
go
ahead.
I'm
sorry
mark
please.
F
So,
just
with
regard
to
providing
similar
functionality
for
the
existing
data
types.
F
So
what
what
we're
doing
in
our
distributed
objective
system
is,
we
classify
passable
objects,
objects
that
can
be
passed
across
the
com
system
into
pass
by
copy
and
pass
by
presence
past
by
copy
those
objects
have
to
be
essentially
frozen,
pure
records
so
they're
very
similar
to
trying
to
approximate
the
records
and
tuples
there's
passed
by
copy
records
that
pass
by
copy
array.
F
So
it's
very
similar
to
to
how
close
you
can
come
with
pass
by
copy
records
and
tuples
in
the
languages
it
is,
and
we've
defined
a
equivalence
class
predicate
called
same
structure
that,
due
to
our
earlier
conversations
in
this
meeting,
I'm
probably
going
to
go
ahead
and
rename
same
key
anyway.
F
In
any
case,
we
do
have
that
less
precise
equivalence
class
that
walks
a
passable
object
and
as
long
as
it
sees
past
by
copy
structure,
it
does
compare
by
content
order,
independent
content
and
then
it
and
then,
when
it's
when
it
reaches
the
leaves
of
the
pass
by
copy
portion,
are
very
compared
to
the
object.
That
is
so.
That
is
an
example
of
what
you
could
do
and
we
also
even
plan
to
have
passable
collections
in
which
the
passable
collection's
indexing
is
equivalence
according
to
same
structure.
D
F
Of
patrick
is
the:
is
there
anything
you
can
do
on
your
side
to
make
the
audio
clearer
or
louder.
D
Is
it
better?
No
is
it
for
your
back?
Yes,
is
it
better?
Yes,
okay,
so
my
comment
was
just
that
there
are.
There
are
several
object,
programming
language
that,
if
deep
equality
and
deep
copy
and
so
on-
and
they
didn't
seem
to
require
specialized.
D
Types
like
crickets
or
topples,
or
and
so
on,
so
maybe
it's
it's
somewhere
to
specify
what
it
means
in
javascript,
but
but
then
we
we
will
achieve
something,
and
instead
of
taking
the
problem
backwards
and
saying
we
want
deep
equality,
let's
find
some
structure
that
allow
that
it's.
It
looks
like
a
an
easy
on
the
side
path
towards
something
that's
that
could
be
relevant
and
the
same
to
second,
what
peter
said
the
same
thing
could
be
said
about
immigrability.
D
There
are
like
several
things
in
the
language.
The
most
stupid.
One
is
date
like
you
can
throw
you
can
freeze
the
date
and
still
change
it.
Okay.
There
are
many
examples
like
that
and
all
the
things
which
would
be
to
I
mean,
from
my
point
of
view,
more
interesting
to
address
that
to
come
with
something
that
is
by
nature
immutable.
D
A
F
Sorry,
I
was
muted
the
I'd
like
to
expand
on
that
a
little
bit
as
well
expanding,
in
particular
on
some
earlier
conversations
that
a
gorick
and
model
have
had
about
our
joint
need
for
immutability.
That's
very
that's
goes
well
beyond
transitive
frozen,
so
we
have
something
the
oracle
library
called
harden,
which
is
just
transit
of
frozenness.
F
That
goes
over
the
object
structure,
reachable
by
property
controversy,
so
that
heart,
that's
hardening
api
surface,
but
has
nothing
to
do
with
immutability
immutability.
It
just
has
to
do
with
tamper
proofing
the
then
what
a
gorick
has
a
need
for
that
fits
very
well
with
what
moddable
has
done
by
other
means
is.
We
would
like
to
be
able
to
mark
some
modules
as
intended
to
be
pure
modules,
meaning
that
they
have
no
top
level
state
and
therefore
can
be
shared.
F
The
import
can
give
you
the
same
module
instance
without
creating
a
communications
channel
if
there's
no
mutable
state
reachable
from
that.
The
other.
The
place
where
this
shows
up
in
the
multiple
technology
is
both
their
snapshot
operation
when
they're
cutting
a
wrong,
and
they
have
right
now
an
interesting
two
argument.
F
Freeze
that
has
an
element
of
this
and
what
what
those
two
things
do
is
as
they're
traversing
a
structure
if
they
see
something
that,
by
its
nature,
is
not
able
to
be
made
immutable
like
a
closure
closing
over
a
lexical
variable
that
is
assigned
to
then
it
aborts
with
air.
F
So
for
our
for
for
our
drawing
purposes,
what
we're
thinking
of
doing
is
proposing
a
harden
and
proposing
a
purify
where
purify
is
like
harden
in
terms
of
the
traversal
that
it
does,
but
it
also
blows
up
if
any
of
the
objects
that
it's
hardening
are
not
made
immutable
by
the
act
of
hardening
it.
If
it
remains
mutable
state
after
hardening,
then
then
it
throws
an
error.
F
Instead,
that's
not
something
you
can
do
in
the
language,
so
purify
would
definitely
be
a
new
primitive,
because
there's
no
way
in
the
language
to
tell
that
something
has
remaining
mutability.
If
its
surface
is
altered,.
C
And
mark
so
an
example
of
that
would
be
a
private
variable
on
an
instance,
for
example,
a
private
field.
Sorry,
on
an
instance.
F
That's
right,
a
private
field
or
a
closed
over
lexical
variable.
Both
of
those
are
great
examples
of
that
unresolved
promises
date,
instances
perhaps
depending
on
what
standards
we
want
to
take
on
them.
You
know
either
we
say
that
that
we,
you
know
either
we
extend
the
meaning
or
purify
it
so
that
it
actually
makes
some
things
like
date,
instances
immutable
or
we
have
purified,
throw
and
error
those.
Those
would
be
the
two.
Those
would
be
the
only
possible
two
choices,
but
it
is
a
choice.
A
Like
I'd
like
to
call
on
bradley
he's
had
his
hand
up
for
some
time
and
if,
since
enough,
people
are
using
the
hand
raising
protocol,
if
you
can
use
that
to
queue
up
your
questions,
that
would
be
helpful
for
procedure.
Bradley.
G
Sure
so
it
it
sounds
interesting
that
we
have
started.
This
conversation
is
basically
a
claim
that
records
in
tuples
tuples
are
not
necessarily
congruent
with
the
rest
of
the
language
and
now
we're
expanding
in
a
direction
which
I
think
is
good
about
a
different
idea,
which
is
not
the
convenience
of
records
and
tuples
themselves,
but
the
capabilities
the
records
and
tuples
are
providing
so
the
deeper
quality.
The
immutability,
I
think,
having
a
convenience
of
records
and
tuples
is
good
in
my
ability
to
write
such
code.
G
Using
methods
consistently
is
difficult,
especially
if
you're
working
on
a
large
team
and
enforcing
their
usage
is
also
difficult,
but
with
the
ability
to
do
quick
checks
for
deep
immutability,
quick
checks
for
shallow
immutability,
and
things
like
that.
G
It
feels
like
the
claim
that
records
in
tuples
are
entirely
incongruent
would
not
be
true,
so
it
seems
like
maybe
the
way
to
unify
records
and
tuples
with
the
design
of
the
language
as
a
whole
is
merely
to
sketch
out
what
it
would
take
to
apply
the
same
principles
to
our
existing
object
and
value
structures.
B
Yeah,
I
totally
agree
with
what,
with
what
bradley
just
said,
though
the
last
part
I
don't
know
exactly
what
it
means,
but
the
way
that
the
way
that
I
analyze
situations
like
objects
with
private
fields
or
dates
or
maps,
or
literally
anything
with
it
with
an
internal
slot
that
that
mutates
is
that
these
just
are
not
they're,
not
immutable
objects,
and
we
could.
B
We
could
make
immutable
versions
of
them.
I
think
things
like
temporal,
where
we
make
those
internal
slots
different,
be
mutated,
are
our
step
in
this
direction.
I
do
want
to
try
to
understand
more
what
what
peter
and
patrick
are
suggesting
about
alternatives
to
how
we
could
move
forward.
B
Instead,
we
have
triple
equals.
That
is
reliable,
that
has
reliable
semantics
and
records
and
temples
are
provide,
provide
a
definition
of
equality
which
is
both
deep
and
reliable
or
recursive
and
reliable.
So
this
topic
of
reliability
is
something
that
kind
of
distinguishes
javascript
from
other
object-oriented
languages
that
I
think
that
this
group
is
especially
interested
in
fostering.
So
that's
that
was
a
big
reason
for
it
for
the
design
to
go
in
this
in
this
particular
direction,
and
so
I'm
wondering
how
we
should
be
making
this
kind
of
trade-off.
B
F
B
Do
we
do
we
want
to
do
something
else?
Maybe
probably
there
are
other
ways
that
we
can
go
about
this,
but
if
you
know
we're
not
going
to
change
the
definition
of
equality
on
objects,
maybe
there's
some
other
higher
level
protocol
that
we
can
make.
That's
more
like
the
java
situation.
Where
java
you,
you
do
have
double
equals,
but
then
you
also
have
the
equals
method,
though,
that
that
could
be
another
way
of
achieving
the
same
kind
of
thing.
I'm
not
I'm
not
really
sure.
F
Yeah
there's
also,
I
want
to
raise
there's
one
absolute
difference
of
something
that
records
and
tuples
can
do
that.
No
variation
of
objects
can
do,
and
this
is
actually
only
the
variant
of
records
and
tuples
that
we
started
with
were
the
primitive
types
where
they're
not
intrinsically
bound
to
a
prototype
where
they're,
which
is
a
deeply
immutable
record
and
tuple
structure,
can
be
passed
between
threads
between
workers,
whatever
you
want
to
call
them.
F
A
I
believe
daniel
addressed
his
question
to
peter,
but
bradley
and
patrick,
are
in
the
queue
ahead
bradley.
Let's,
let's
go
with
patrick
okay,
patrick.
D
Oh,
yes,
what
it
all
depends
on
the
where
and
all
the
prototypes
are
where
there
are
so
in.
We
can
transfer
objects,
instance
from
one
worker
to
another,
one
one
thread
to
another,
because
their
prototype
is
itself
a
of
completely
frozen
object
in
in
home,
which
is
shared
by
all
the
objects
in
all
the
workers.
D
So
in
fact
the
I.
I
completely
of
course
understand
that
if
you
have
separate
prototype
and
separate
song,
it
doesn't,
it
doesn't
work,
but
in
fact
living
in
a
like
the
frozen
world
that
we
set
up
to
run
the
the
different
machine
in
the
different
worker
and
so
on.
You
can
you
can
really,
and
we
do
that,
all
the
time
I
mean
like
you,
we
can.
You
can
really
pass,
because
the
the
prototype
itself
is
share
among
all
the
the
worker
and.
C
G
Sure
one
second,
so
we've
been
taking
a
little
bit
of
a
different
direction
than
I
thought
we
started
talking
about
different
protocols.
We
could
apply
to
objects
in
the
past
kevin
gibbons
and
I
have
proposed
extensions
to
collections
for
normalization
and
for
identity,
and
we've
made
some
arguments
in
the
past
at
the
committee
about
why
we
would
not
want
to
apply
a
hash
code
like
design
to
objects
where
the
hashcode
is
on
the
object
itself.
It
would
instead
be
applied
to
some
operation.
G
G
Regarding
things
like
the
ability
to
actually
share
across
multiple
threads
in
this
exact
problem,
webkit
javascript
core
has
a
blog
post
from
2017.
I
believe
where
they
propose
that
and
at
the
same
time
there's
a
lot
of
feedback
on
issues
about
sharing
the
prototype
across
threads.
G
So
it
might
be
good
to
look
back
at
that.
That's
all.
A
We're
coming
close
to
end
of
time.
I
think
it
would
be
great
to
hear
from
daniel
and
peter
for
to
wrap
up
the
conversation
where,
where
you
stand
at
the
moment
and
what
you
would
like
to
see
going
forward.
C
Sure
I
I
thought
yeah
since
daniel
had
dan
had
left
a
question
to
me
in
his
last
statement,
I'll
I'll
address
that
briefly,
if
that's
okay,
so
the
questions
of
operator
overloading
and
how
equality
is
handled
are
thorny
and
dan.
You
know
them
way
way
better
than
me,
so
I
won't
even
attempt
to
recount
them.
C
I
I
think
what
patrick
implied
at
one
point,
at
least,
if
not
said,
is
that
deep
equality
is
generally
useful
and
I
think
that's
that's
not
controversial
and
it's
it's
useful
with
objects
which
are
mutable
and
immutable
and
the
so
so
that
that's
something
where
we
think
we
can.
We
could
pursue
that
in
a
way
that
would
be
useful
to
javascript
developers.
More
broadly,
it
could
be
a
and
a
reasonable
first
step,
for
that
would
be
something
that
this
committee
has
done
many
times,
which
is.
C
I
know
this
is
the
committee,
but
I'm
used
to
talking
like
that
that
we've
done
many
times,
which
is
to
introduce
something
using
just
kind
of
standard
instances
and
methods
and
and
sidestep
syntax
question,
and
if
that
mechanism
indeed
becomes
popular
and
and
there's
reason
to
believe
deep
equality,
would
I
I'm
not
suggesting
otherwise?
But
if
that
mechanism
becomes
popular,
then
we
can
address
the
syntax
question
afterwards.
C
And
if
you
take
that
approach,
then
you
get
something
which
is
very
nice,
which
is
explicit
when
you
want
deep
equality,
because
I
I
know
I
know,
there's
been
an
argument
made
that
the
syntax
is
necessary
because
that's
what
people
expect.
They
expect
a
deep
comparison
when
they
have
a
record
in
tuple.
But
but
from
my
perspective,
javascript
has
always
had
objects
and
objects
have
never
compared
by
contents
and
records.
Look
a
whole
lot
like
objects
and
so
like.
C
I
would
find
it
surprising
if
they
compared
deeply
and
I'm
not
saying
I'm
right
or
you're
wrong.
I'm
just
saying
I
think
I
think
there's
there's
there's
different
perspectives
to
take
that
lead
you
to
different
conclusions
on
that.
So
I
mean
in
wrapping
up
sir,
I
don't
mean
to
speak
for
too
long.
I
think
the
conversation
is
has
been
great.
C
I
don't,
I
don't
see
a
huge
amount
of
difference
in
the
the
goals
of
where
we
would
all
like
to
see
landing,
but
I
think
there's
work
left
to
do
and
understanding
understanding
how
we
might
we
might
get
there
and
what
what
the
the
viable
options
really
are.
B
Yeah,
I
agree
that
there's
work
left
to
do,
and
I
I
probably
shouldn't
have
even
mentioned
operator
overloading
a
method
based
protocol
definitely
sounds
like
the
better
way
to
start.
So
I
agree
with
you.
There
it
seemed
like
bradley
was
expressing
some
concerns
about
a
method
based
protocol,
so
I
think
it'd
be
good
to
dig
into
this
more
at
a
further
meeting.
B
A
Oh,
that's
probably
for
the
people
who
wish
to
be
to
participate
in
this
conversation.
This
time
is
available
and
you're
welcome
to
propose
it
as
an
agenda
item
at
a
future
meeting.
If,
especially
given
that
this
is
a
a
good
time
slot,
where
we
can,
where
we
regularly
meet
anyway,
but
if
there's
a
better
venue
for
the
conversation
that
that
peter
bradley
and
yourself,
as
at
least
and
and
other
interested
parties
are,
are,
are
all
available
to
have
that
conversation.
A
B
Yeah
could
could
people
who
are
interested
in
discussing
this
further
sort
of
note
this
in
the
chat,
and
then
I
can
make
sure
to
contact
you
all
for
for
a
follow-on
for
for
staying
in
touch
on
this
topic.
A
Awesome,
thank
you.
I
would
like
to
proceed
to
resuming
the
presentation
on
cess
is
that
all
is.
Is
that
good?
F
A
A
One
moment
yeah:
that's
right:
we
went
through
our
glossary,
which
is
the
next
slide
and
just
to
recap
briefly,
since
there
are
some
folks
here
who
were
not
there
last
week,
resolution
and
module
specifiers
are
defined
in
a
way
that
there
is
a
logical
resolve
that
is
intrinsic
to
multiple
compartments
into
the
synchronous
and
some
which
is
distinct
from
resolve
in
the
node
ecosystem,
where
it
is
an
asynchronous.
A
It
is
potentially
hiding
io
behind
it
that
discovers
that
discovers
the
the
corresponding
specifier
in
the
compartment
proposal.
This
behavior
is
divided
between
the
resolver,
which
is
synchronous
and
the
load
specif
the
load
hook,
which
is
async.
A
Then
the
load
hook
is
responsible
for
canonicalization
and
such
which
is
under
presumably
an
internal
locate
method,
which
is
followed
by
an
internal
retrieve
and
a
parse
and
an
analysis
and
providing
a
module,
a
module
record,
and
then
loading
is
transitive
and
driven
from
the
outside
and
is
the
first
phase
of
the
first
phase
of
import,
but
doesn't
cause
any
modules
to
be
initialized,
and
we
discussed
some
of
the
details
of
of
initializing
modules,
which
I
call
execute,
and
I
think
I
will
change
to
initialize
in
any
documentation
we
produce
out
of
this.
A
In
order
to
be
consistent,
yeah
and
we
m,
and
last
week
we
made
some
some
refinements
to
these
definitions.
To
be
particularly
clear
about,
like
in
particular,
dynamic
import
within
a
compartment
is
aware
of
the
surrounding
module
referrer
and
unlike
the
external
compartment,
import
method,
which
is
which
requires
a
full
specifier
as
an
argument
and
then,
of
course,
top
level
await,
causes
some
complications
to
the
design
that
we
have
not.
We
have
not
addressed
and
are
not
ready
to
propose
changes
yet
but
open
to
there.
A
There
are,
I
have
slides,
to
discuss
that
yeah
and
then,
of
course,
there
are
some
distinctions
between
module
sped
did.
I
don't
believe
we
saw
this
slide
last
week.
Is
that
correct
anybody
who
was
here
last
week
is
this?
Is
this.
A
Okay,
so
within
the
compartment
proposal,
the
distinction
between
absolute
and
relative
specifiers
is
is,
is
is
moot
it
is
these
are.
A
These
are
terms
that
are
are
specific
to
a
particular
domain
of
module
specifier,
for
example,
web
module,
specifiers
or
node
module
specifiers
and
multiple
node
module
specifiers
in
particular,
and
are-
and
we
are
attempting
with
this
design,
to
make
this
plugable
so
that
the
compartment
api
can
serve
as
a
foundation
for
unifying
those
environments,
an
environment
where
you
could
use
a
compartment
different
compartments
with
different
res
module
resolution.
Semantics
the.
A
But
the
distinction
between
a
full
and
partial
specifier
is
relevant
to
the
compartment
api,
because
full
specifiers
are
used
as
cache
keys
or
memo
keys
for
the
purpose
of
of
of
recording.
What's
known
about
what
modules
have
been
loaded,
what
modules
have
been
executed
and
what
their
namespaces
are?
The
and
again
the
node.js
resolve
function
does
io
behind
the
scenes
and
so
that
behavior
in
the
compartment
api
would
be
divided
between
the
resolve
hook
and
the
load
hook,
and
then,
of
course,
the
resolve
and
load
hook.
A
Collaborate
to
produce
the
name
space
for
a
particular
to
define
the
module
identifier
namespace
in
a
particular
compartment
and
the
resolve
hook,
is
sufficiently
general
that
that
function
can
be
used
for
all
compartments
of
the
same
kind.
All
compartments
that
use
a
particular
domain
for
module
for
module,
particular
math
for
module
specifiers
to
get
concrete.
A
The
the
module
specifier
namespace
in
node
in
a
style
that
would
allow
would
be
compatible
with
moddables
xs
and
the
the
distinction
here
is
that
node
at
the
moment
is
effectively
similar
to
the
web,
in
the
sense
that
all
modules
are
running
within
the
same
compartment
right,
any
module
can
link
any
other
module
in
that
namespace
and
they
use
fully
qualified
urls
as
as
as
full
specifiers
in
the
moddable
xs
world
compartment
is
used
to
create
isolated
namespaces
in
each
compartment,
and
the
specifiers
are
closer
to
what
you
would
see
in
a
package
json
the
they're.
A
They
are
not
fully
qualified
urls,
they
are
they.
They
come
in
two
flavors
one
is
a
relative,
so
so,
okay,
so
a
bear.
Some.
Some
people
have
called
this
a
bear
specifier,
which
is
absolute
in
the
note
sense
and
full
in
the
compartment
sense
and
in
the
modable.
Excess
sense
always
refers
to
something
that
is
externally
linked
either
in
in
the
modelable
sense,
it's
usually
from
the
parent
in
the
session
sense.
A
It's
in
the
node
semantics
of
module
specifiers.
You
can
use
relative
relative
path,
components
in
including
dot
and
dot
dot,
and
then
these
get
erased
by
resolve,
except
for
the
distinction
between
the
dot,
slash
prefix,
which
means
it's
internal
and
bear
specifiers,
which
means
it's
external
and
for
sake
of
completeness
there
there
is
not
a
complete
cross
product
of
absolute
and
relative
versus
full
and
full
and
partial.
A
There
is
no
in
the
node
semantics,
there's
no
such
thing
as
a
relative,
full
module,
specifier
or
an
that
is
your
second
bullet.
Just
yeah,
that's
identified!
There's
such
a
thing!
Yes,
I'm
sorry,
let's
see
if
I
can
reason
this
out
on
my
slide.
A
We
have
absolute
and
full
relative
and
full
relative
and
partial
and
we're
missing
absolute
and
absolute
and
partial
okay.
Yes,
if
I
may
absolute.
A
A
A
This
is,
this
is
an
explanation
of
a
particular
of
a
of
a
particular
resolve,
math
that
is
consistent
with
modables
use
of
xs
and
the
and
the
module
identifier
namespace
implied
by
their
use
of
the
compartment
api.
A
That
is
also
consistent
with
node's
use
of
module
identifiers
and
it,
and
it
is
an
explainer
of
the
distinct
where
the
line
is
between
what
is
meaningful
to
a
compartment
and
what
is
meaningful
to
the
resolved
semantics
specific
to
this
particular
kind
of
namespace,
where
absolute
and
relative
are
relevant
to
this
domain.
A
But
absolute
and
partial
and
full
are
relevant
to
the
compartment,
and
this
is
this
is
a
slide
I
feel
compelled
to
share,
because
I
found
it
in
insightful
that
there
was
a
distinction
between
these
two
dimensions
and,
in
particular
that
that
distinction
was
important
for
expressing
this
particular
style
of
linkage
and.
H
A
H
So
the
the
other
one
is
more
like
a
comment
as
well
I
so
this
looks
a
lot
like
the
effort
that
we
did
for
the
module
loader
api
few
years
by
since
then
we
got
a
lot
of
pushback
from
especially
from
the
web,
about
having
this
level
of
level
of
control.
H
Now,
where
you
have
a
lot
more
control,
you
don't
define
the
maps,
you
don't
define
how
to
get
the
modules
or
where
the
modules
are
already
being
created,
or
so
on.
You
you,
in
the
case
of
input
maps,
it's
just
a
lot
more
static,
it's
more
like
an
initialization
process
rather
than
at
runtime,
yes,
resolution.
So.
A
Yes,
my
proposal
is
that
the
pitch
is
that
import
maps
are
import.
Maps
are
going
to
be
an
area
of
rich
innovation
in
and
could
be
an
area
of
rich
innovation
in
user
space
for
the
purposes
that
import
maps
are
very
useful.
We've
already
seen
many
many.
A
Conversations
about
how
these
things
could
be
implemented,
and
it
would
be
useful
to
have
some
foundation
primitive,
that's
useful,
to
implement
this
style
of
solution
and
by
creating
a
module
loader
api,
which
is
what
we're
proposing
the
compartment
api,
be
at
some
particular
layer
that
we
are
making.
We
are
introducing
a
an
a
component
to
the
language
that
is
consistent
with
the
web
manifesto,
which
many
of
these
people
have
signed
of,
of
providing
the
primitives
that
are
that
are
providing
primitives
that
allow
exploration
of
solutions
in
user
space.
A
We
do
not
see
this
proposal
as
inconsistent
with
import
map,
but
as
a
primitive
that
makes
it
possible
to
implement
import
maps
in
more
ways
than
just
what
the
browser
vendor
provides
and
also
do
so
in
a
way
that
could
be
used
to
unify
the
to
be
used
as
a
bridge
to
close
the
gap
between
the
web
and
all
others.
H
H
So
browsers
can
do
a
lot
of
things
there,
optimization
wise
and
so
on,
because
you
don't
have
to
call
a
a
function
in
user
land
to
do
something
during
that
process,
and
I
think
that
that
would
be
their
position
once
we
go
on
percentage.
So
we
need
to
be
very,
very
careful
about
this,
because
every
time
that
you
have
a
very
complex
process
and
loading
and
initialization
and
so
on
and
modules
is
very
complex
and
you
have
the
uncertainty
of
potential
user
lan
code
executing
making
side
effects
and
potentially
throwing
errors.
F
Let
me
mention:
let
me
mention
that
there's
a
very
interesting
middle
ground
that
is
already
something
we're
paying
a
lot
of
attention
to
because
of
model's
typical
configuration
in
tc
53,
which
is
the
subset
of
this
proposal.
That
applies
when
all
of
the
modules
are
of
concern
have
already
been
turned
into
modular
static
records.
F
Basically,
the
modable
pre-compiled
for
all
the
source
code
exists
only
during
development
time
and
then
all
you're
doing
in
runtime
is
making
new
instances
in
different
compartments
and
wiring
them
up,
and
for
that
purpose
it's
crucial
that
we
be
able
to
instantiate
a
given
module
static
record
multiple
times
in
different
compartments,
so
that
we
can
do
least
authority
linkage
and
so
that
we
can
do
isolation
of
mutable
module
instances.
F
So
there's
definitely
flexibility
that
we
need
that
goes
beyond
what
import
maps
don't
even
have
a
notion
of
instantiating
different
modules
in
different
compartments,
and
so
there's
there's
so
there's
definitely
flexibility
that
we
need
that
this
thing
gives
us
gives
to
us
fairly
directly
in
the
scenario
where
we're
only
concerned
about
dynamic
linking
not
dynamic
loading.
F
So
I
think
that's
that's
an
important
thing
to
to
explain
and
I
think
it's
an
important
thing
to
make
clear.
It's
it's
it's
it's
it's
at
midpoint.
The
tc
53
expects
to
be
the
dominant
use
case.
H
H
Mark,
even
in
that
case,
there
are
certain
guarantees
that
you
have
when
you're
going
to
evaluate
something,
even
if
you're
creating
a
new
intent
for
a
new
compartment.
There
are
certain
guarantees,
because
you
already
validate
most
of
the
of
the
things
that
needs
to
be
carry
on
during
the
initialization
or
evaluation
process.
So
I
think
that's
that's
going
to
be
the
biggest
challenge.
H
A
The
in
particular
daniel
made
a
point
in
in
chat
that
that
I,
that
I
agree
with
that,
it
is
possible
that
the
compartment
api
could
could
ride
in
in
a
world.
Apart
from
the
the
the
compartment
of
the
web.
A
B
Saying
that
I
was
saying
I
think,
there's
there's
something
that's
sort
of
even
worse
about
a
loader
api,
where
you're
hooking
into
how
the
current
compartment
is
being
loaded.
The
current
how
the
whole
gauge
is
being
loaded
compared
to
this
compartment
api,
where
you're
making
a
new
compartment
where
imports
within
the
compartment
call
into
these
comparative
hooks.
B
B
So
I
agree
with
with
garrity
that
if
we
can
express
things
in
terms
of
things
that
can
be
pre-computed,
then
it
will
be
seen
to
be
more
optimizable,
but
then
it
also
risks
putting
us
into
a
corner
where
it's
not
expressive
enough.
So.
A
I
think
yeah,
I
think
that
the
compartment
api
does
not.
Actually,
I
think
that
it
will
be
possible
to
address
any
such
concerns,
because
the
compartment
api
does
not
itself
need
to
make
strong
claims
about
about
the
about
order
of
linkage
and
such
we
can.
We
can
make
it
compatible
and
does
not
serve
this
anything
that
it.
I
do
not
believe
it
surfaces
any
component
of
the
api
that
forces
it
to
be
implemented
in
a
particular
way.
I
Sure
I
just
wanted
to
add
that
I
mean
I
think
it's
worth
listening
quite
carefully
to
what
karate
has
to
say
here,
because
the
experience
from
the
loader
api
and
and
the
sort
of
issues
that
came
up
with
that
are
do
have
the
same
effect
on
compartments
here,
because
it's
hitting
those
same
roadblocks
potentially
so
as
we're
thinking
about
how
it
gets
past
those
issues
that
that
loaders
couldn't-
and
you
know
if
there
were
specific
things
I
mean
even
just
to
speak
to
the
resolver-
you
know.
I
A
Yeah
I
wish
I
could
put
a
preaching
for
those
conversations.
We'll
have
to
dig
up
more
references.
I
But
just
to
mention
briefly
and
then
I'm
done
when
you
brought
up
the
example
of
reinstantiation
within
a
compartment.
I
If
you
were
using
a
built-in
scheme
for
your
effectively
pre-passed
or
sort
of
pre-processed
code,
you
still
have
to
make
the
decision
about
if
you're
going
to
use
the
same
linkage
or
a
different
linkage
in
the
new
compartment.
That's
right!
You
have
a
built-in
scheme
for
that
pre-linked
or
sorry
pre
pre-processed
code.
I
You,
you
can
use
that
built-in
scheme
with
an
import
map
to
then
decide
if
you
want
to
have
the
same
linkage
or
new
linkage
while
still
supporting
that
kind
of
a
use
case,
and
so
I
think
it
can
map
to
the
maps
the
import
maps
as
it
were,
but
maybe
that's
a
discussion
to
have
separately
yeah.
A
Okay,
I
think
that,
given
that
we
are
at
at
time,
I'll
stop
my
share.
A
Let's
I'm
going
to
stop
the
recording.
Thank
you.