►
Description
Viability Records and Tuples for Stage 3 with Daniel Ehrenberg and champions of Records and Tuples. MarkM brings a concern regarding -0, which the champions address. A concern remains about the coherence of the language, given that some of the goals of tuples and records as suitable as keys in maps and values in sets might be achievable with other means that preserve amortized constant time comparison.
Upcoming changes to Node Policies due to Import Maps (5min) with Bradley Farias. Node.js will allow an escape hatch in policies that will open up ambient authority to import maps. Module specifiers will be eagerly canonicalized into the domain of fully qualified URL or something else that looks like a path relative URL but must not begin with . or .. path components.
Isolated Realms, new API Review with Caridy and Leo.
C
B
D
B
In
our
discussions
with
browsers
so
far,
it
seems
like
people
are
happy
with
that,
as
long
as
we
communicate
this
clearly
to
javascript
developers
and
make
sure
to
avoid
the
expectation
that
comparisons
be
constant
time.
This
was
actually
an
insight
that
robin
had.
I
thought
it
would
have
been
essential
to
make
comparisons
constant
time,
but
this
does
end
up
being
kind
of
prohibitively
complex.
B
C
B
C
So
I'm
certainly
happy
with
that
that
performance
course.
So
let
me
just
make
sure.
Let
me
let
me
let
me
let
me
restate
to
make
sure
I
understand
what
these
situations
that
the
semantics
that
we
all
like
best,
the
one
that
I
just
stated
is
now
one
that
the
browser
makers
agree
to
implement.
Is
that
correct.
B
C
Okay,
so
so
that
was,
that
was
the
hard
constraint.
So
so
congratulations
on
getting
past
that
the
other,
the
other
issue,
I'm
very
glad,
peter's
on
the
line,
the
other
issue,
the
one
that
peter
brought
up
peter
and
patrick,
brought
up
the
model
that
I'm
very
sympathetic
with
that.
I
want
to
talk
through
and
with
peter
here.
Now
is
a
great
time
to
talk
and
with
this
crowd
here
now
is
a
great
time
to
talk
it
through,
which
is
we
already
have
frozen.
C
C
We
need,
you
know,
we're
we're
working
towards
a
hardened,
primitive,
a
purify,
primitive,
a
notion
of
pure
modules,
ones
that
don't
have
top
level
immutable
state
and
the
main
thing
that
I
thought
you
couldn't
get
to,
starting
with
immutable
objects
that
you
could
get
through
with
records
and
tuples
was
the
ability
to
have
multiple
agents.
I
I
hate
the
term
agents
but
I'll
use
it.
C
C
They
can
actually
do
what
what
I
I
I'll
I've
relabeled
their
insight
as
a
multi-agent
realm.
So
it's
it's!
The
idea
is
that,
once
all
of
the
shared
prime
primordials
are
transitively
immutable,
then
transitively
immutable
things
can
also
be.
You
can
actually
have
multiple
agents
sharing
the
same
set
of
transitively,
immutable,
primordials
and
because
they're
creatively,
mutable,
there's,
there's
no
there's
no
concurrency
problem
yet
and
then,
when
you
pass
messages
between
the
agents,
any
root
object,
that's
a
root
of
a
completely
transitively
immutable
gr.
C
Subgraph
can
also
be
passed
by
pointer
sharing
rather
than
copying,
because
the
realm
that
it's
in
is
the
realm
that
both
sides
share.
So
it's
this
really
peculiar
thing
that
I've
never
thought
of
before,
where
you
really
have
a
concept
of
of
multiple
agents
sharing
one
realm,
but
every
state
from
which
any
mutable
state
is
reachable
is
completely
partitioned
between
the
agents,
even
though
they
share
one
realm
and
as
far
as
I
can
tell
all
of
that
makes
perfect
sense
and
peter
am
I
getting
the
idea,
even
though
putting
my
my
spin
on
it?
F
F
A
C
B
I
see
so
so
I
agree
that
this
concurrency
cases
is
really
important
in
the
past.
I
was
pessimistic
that
we
would
be
able
to
achieve
it
with
records
and
tuples,
because
it
will
take
a
big
effort
on
the
part
of
javascript
engine
implementers
to
support
a
multi-threaded
heat,
but
I've
heard
some
interest
from
them
in
looking
in
that
direction,
I
don't
wanna,
I
don't
wanna
overestimate
this
into
commitment,
but
there's
there
seems
to
be
interest
and
I
and
I
think
that
would
work
well
with
with
records
and
tuples.
B
I
think
it
would
be
nice
if
we
had
a
clear
dividing
line
between
what
you
can
and
can't
share
and
don't
have
like
a
performance
cliff
where
you
accidentally
copy
something,
and
you
don't
really
see
that
explicitly
in
the
source
code.
You
don't
you
don't
have
an
easy
and
you
know
a
straightforward
rule
to
follow,
but
there's
a
separate,
fundamental
capability
that
we
get
with
records
and
tuples,
which
I
don't
know
how
to
achieve
with
objects.
G
C
We
call
it
same
structure
which
is
a
terrible
name,
but
basically
another
equality,
predicate
that
simply
ignores
the
identities
of
the
of
the
the
immutable
objects
and
does
a
recursive
structure
compare
and,
and
that
can
be
written
in
user
code.
There's
no
reason
for
that
to
be
provided
by
the
engine
and
like
with
zero
versus
minus
zero
there's
a
cost,
which
is
that
things
which
are
are
equal
by
this.
Looser
equivalence
class
are
still
distinguishable
by
more
accurate
equality
predicates.
B
Yeah
peter
peter
suggested
that
to
us
as
well
that
we
could
use
a
different
equality
predicate
for
a
structural
comparison
and
we
thought
about
it,
and
I
guess
this
was
again
an
insight
from
from
robin,
especially
that
having
these
multiple
equality
predicates
would
probably
lead
to
worse
developer
experience
where
and
it's
not
just
about
like
switching
out
your
triple
equals
for
this
new
predicate.
It's
also
about
every
place
that
equality
is
embedded
into
maps
and
sets
are
one
clear
case.
B
C
B
So
I
I
agree
that
we
should
go
forward
with
things
like
your
read-only
collections
proposal.
I
think
those
will
be
really
beneficial
if,
if
we
had
a
way
to
solve
this,
that
was
more
unified
that
met
the
user's
needs.
I
think
that
would
be
great,
but
I
also
think
that
the
proposal
brings
a
lot
of
benefits,
so
that's
kind
of
why
or
what
will
work?
I
don't
know
yeah.
E
E
That
being
said-
and
I
I
think
we
already
talked
about
it,
which
is
identity,
less
objects,
which
is
essentially
extending
the
object
behavior
to
to
support
records
and
tuples
through
that
mechanism.
I
I
wonder
what
you
would
think
if
it's
more
acceptable
that
way,
rather
than
the
primitive,
primitive
approach.
Sorry,
but
yeah.
B
And,
from
a
user
perspective,
we're
really
trying
to
smooth
everything
over
by
making
everything
as
analogous
as
possible.
So
you
so
you
use
the
same
kinds
of
idioms
and
you
just
you
know.
A
developer
will
know
that
they're
using
a
record
or
tuple
instead
of
an
object
but
they'll
be
able
to
translate
all
their
existing
knowledge
of
objects
and
frozen
objects
in
particular
to
to
the
use
of
this.
D
I'm
sorry
I'm
I'm
I'm
I'm
back
in
this
conversation.
I
still
don't
understand
mark's
concern
very
well
with
the
current
proposal
can
can.
Can
someone
spend
like
a
minute
trying
to
explain
what
what
what
the
issue
is
trying
to
read
right
now
see
if
it
could
catch
up,
but
I'm
I'm
not
catching
up.
So
we
need
some
help
here.
C
F
I
mean
the
the
the
short
summary
is
easy
and
the
so
that's
that's.
What
I'll
stick
to
javascript
has
a
clear
direction
in
how
it
handles
immutable
objects.
Today
this
is
object.
Freeze,
we
moddable
that
work
on
immutability
in
the
language
should
proceed
along
that
route
in
a
way
that
adds
immutability
to
built-ins
in
general.
F
The
work
that
we've
done
in
the
model
sdk
for
quite
some
number
of
years
now,
in
fact,
does
exactly
that.
So
we're
not
because
we
put
objects,
instances
of
built-ins
into
rom
all
the
time
where
they
are
truly
physically
immutable.
So
we
know
that
this
can
work.
We
know
what
it's
like
to
program
with
it.
We
know
what
it's
like
to
implement
it.
F
We
could
have
the
read-only
collections
proposal,
which,
which
is
different.
You
have
date
actual
temporal
which
actually,
in
its
specification
talks
about
being
immutable,
and
I
mean
it's
a
nice
design.
It
does
it
well,
but
it's
a
different
way
of
thinking
about
that
terminology
as
well,
and
we
think
that
immutability
should
be
in
the
language,
a
first-class
consistently
defined
property
that
developers
can
work
with,
and
records
and
tuples
takes
us
away
from
that.
Monable
is
not
suggesting
that
the
way
that
we
do
it
today
is
the
right
way
for
the
entire
language.
F
F
B
So
we've
had
some
conversations
with
with
peter
and
patrick
and
I'm
grateful
that
they
they
took
the
time
to
do
so,
but
we
weren't
able
to
figure
out
how
to
meet.
At
least
I
wasn't
able
to
understand
how
we
could
meet
the
goals
of
the
records
and
doubles
proposal
in
the
context
of
just
javascript
frozen
objects.
I
mean
in
some
sense
records
and
doubles
are
frozen
like
the
is
frozen.
Predicate
will
return
true
for
them,
but
but
they
also
have
this
additional
quality
of
being
identity-less.
D
C
D
A
And
also
that
is
being
frozen,
I
believe,
is
insufficient
for
being
usable
as
a
key
in
a
map
or
set
right
yeah.
So
so
the
idea
is
which
I
find
compelling
is
that
being
transitively
frozen
is
a
good,
baseline
and
foundation
from
a
language
perspective
that
it
is
consistent
with,
but
the,
but
it
also
doesn't
meet
the
requirements
of
being
usable
as
a
key.
B
I
guess
if
we
wanted
to
make
a
separate
predicate
for
this
structural
equality,
then
we
would
make
like
a
structural
map
and
a
structural
set,
but
what
this
kind
of
direction?
What
I
don't
understand
how
to
solve
with
it
is
with
our
current
equality
operators.
We
get
a
certain
sense
of
integrity
or
we
get.
We
get
a
very
high
sense
of
integrity.
It's
a
built-in
operation,
it
has
syntax
to
use,
and
it's
always
going
to
be
reliable.
B
Well,
that's
true,
but
you
know,
map
uses
a
reliable
equivalence,
class-based
equality
operation
inside
of
it.
I
think
I
think
it
would
be
a
mistake
to
try
to
solve
the
problem
that
records
and
doubles
try
to
solve
by
adding
like
an
equals
and
hash
code
method
to
objects,
because
such
an
approach
would
not
be
would
not
have
this
reliability,
property.
C
C
C
I'm
I
I
don't
know
I
mean
I
I'm
on
the
fence
on
this.
I'm
not
really.
I
thought
with
this
with
the
with
the
minus
equal
thing,
a
blocker
I
knew
which
side
I
was
on
now
that
minus
zero
is
not
a
blocker.
I
sympathize
with
peter's
side.
I
sympathize
with
with
this
other
side
and
I'm
I
myself
am
genuinely
undecided
at
this
point.
B
G
Do
have
an
addition,
even
if
we
focus
solely
on
this
comparison
thing.
It
doesn't
really
solve
me
wanting
to
send
things
across
machines
to
my
knowledge,
so
it'd
be
good
to
understand
how
kind
of
identity
is
not
problematic
when
you
send
it
across
machines,
because,
right
now
you
can
attach
arbitrary
data
to
objects
with
maps
and
side
tables
of
that
nature,
and
that
is
the
main
thing
I
want
to
be
able
to
mitigate
by
having
identity
list
values.
C
G
So,
if
the
way
you
can
do
this
kind
of
today
that
I've
seen
people
do
it,
this
is
not
how
I
do
it
is
you
basically
json.stringify
objects
and
use
that
as
your
key,
and
this
is
actually
not
too
terribly
uncommon
in
javascript,
because
we
lack
identity,
lists
values
so
yeah
anyway,
I
look
forward
to
it.
Okay,
good.
C
But
let
me
let
me
stress
that
the
the
e
distributed
object-
semantics,
although
it'll
be
informative
and
and
be
good
background
for
these
discussions
is
not
directly
an
answer
to
this,
because
it's
it's
there's
a
significant
gap
between
the
distributed,
object,
semantics
and
the
normal
javascript
local
object
semantics.
So.
B
Yeah,
I
think,
there's
a
lot
of
differences
between
how
distributed
objects
and
local
objects
work.
For
example,
the
whole
box
concept
in
records
and
tuples
would
be
a
bit
difficult
to
map
to
distributed
objects.
Unless
you
want
to
have
a
distributed,
garbage
collector,
which
probably
you
don't
want.
E
Yeah
not
to
discuss
that
just
right
now,
but
just
so
you
know
we
are
thinking
about
adding
some
kind
of
realm
check
on
the
box
when
you
unbox
it
so
that
that
would
mean
that
you
can
only
unbox
in
the
original
or
originating
realm.
So
I
don't
know
if
that
alleviates
concerns,
but
yeah.
That's
something.
C
E
That
that's
equivalent,
indeed,
the
main
change
here
being
ergonomic.
So
if
you
are
working
within
one
realm,
like
not
thinking
about
prose
realm,
anything,
it's
just
so
that
framework
authors,
for
example,
can
start
keeping
references
of
something.
That
being
said,
you
can
still
run
trip
the
box
for
a
three
ounce,
so
you
can
send
the
box
somewhere
else.
You
can't
open
it
somewhere
else,
but
you
can
send
it
back
through
another
structure
and
it
will
run
trip
so.
E
G
G
G
G
G
G
G
So
when
you
try
to
create
a
map-
and
it
includes
a
relative
url
string
in
it-
import
maps
will
actually
go
and
try
to
convert
it
to
an
absolute
url
string
eagerly
and
if
they
fail
to
do
so,
they
keep
the
failed
string
as
the
string
to
match
against
it's
just
a
kind
of
weird
semantic.
That
was
exploiting
an
error
path
and
we
can't
really
match
it
because,
since
it's
on
an
airpath,
it
wasn't
something
we
designed
around
yeah.
G
G
That
is
what
browsers
are
using
for
it.
It
is
not
actually
the
escape
hatching
node.
We
have
to
do
some
juggling
because
for
browsers
for
built-in
modules.
So,
let's
say
fs
since
that
is
not
a
valid
relative,
url
string,
it
fails
to
parse
and
they
used
that
error
path
and
they
don't
actually
fully
resolve.
H
G
G
A
H
I
think
you
can
go
through
it,
because
I've
had
a
sync
with
caridi
and
and
daniel
last
friday,
and
we
set
up
like
some
new
advancements
on
this
api.
This
is
based
on
the
polyfill
that
I
presented
last
week,
and
I
want
this
group
to
reveal
it
before
I
push
it
to
the
realms
proposal
back
to
the
realms
proposal.
H
H
D
H
D
H
H
H
H
D
D
D
H
You
actually
provide
still
provide
like
a
module
specifier,
and
you
give
a
string
with
the
name,
the
binding
name,
that
you
want
to
get
the
value
from
this
injected
module
and
still
returns
a
promise
and
yeah.
The
rest
is
a
representation.
It's
not
a
dynamic
mapping
of
the
dividing
foo
from
what
is
imported
there.
H
So
here
I
have
an
example
where
I
have
my
module
file
and
the
incubator
realm
script.
Where
I
get
like
specifier
here,
my
module,
there's
just
a
typo,
and
even
if
I
want
multiple
bindings,
we
can
just
run
these.
They
us
they
just
queue.
Multiple
async
requests,
but
even
though,
like
there
is
only
one
import
there
like
a
one
module
evaluation,
so
you
can
still
use
like
promise
all
import,
multiple
values
so
foo
and
is
just
a
representation
of
the
binding
phone
number.
H
I'm
using
different
names
just
to
see
like
you're,
not
con.
You
can
pick
anything
so
full
n
would
be
42
times.
Two
is
a
function
that
is
exported
there
in
the
the
module
you
actually
get
a
wrapped
function.
This
is
a
bridge
function
so
times
two
is
a
function.
You
see
it's
still
a
function
that
is
created
within
this
incubator
realm
that
just
bridges,
communication
from
the
function
that
was
imported
there
injected
into
this
yeah.
D
I
think
before
we
get
into
the
api,
I
think
it's
important
to
explain
the
meta
model
and
okay.
Hopefully
I
I
hope
that
not
everyone
is
lost
on
this
one.
So
right
now,
but
the
the
main
idea-
and
it
took
a
little
bit
of
time
for
daniel
to
realize
kind
of
what
we.
What
we
were
trying
to
pitch
for
a
few
weeks
is
that
we
want
the
full
separation
between
the
two
realms.
D
But
in
order
for
someone
to
ride
a
program
that
works
well
interacting
between
the
realms,
it's
going
to
be
very
hard
to
do
it.
If
you
don't
have
a
way
to
really
provide
any
synchronous
communication
between
the
two
sides
and
when
we
say
synchronous,
communication
is
just
calling
a
function.
Basically,
that
does
something
on
the
other
side
and
and
for
that
reason
the
the
simplification
that
we're
proposing
is
that
anything
that
comes
out
of
the
realm?
D
D
What
you
get
is
a
new
function
that
is
native
that
when
invoke
just
invokes
the
the
function
from
the
other
round
and
that
process
works
both
ways,
not
only
when
the
incubator
is
asking
asking
the
rom
to
do
something
like
give
out
or
infor
binding,
you
get
a
function,
you
get.
What,
while
leo
is
calling
a
wrapping
function?
It's
just
a
function.
D
It's
kind
of
a
binding
function
function
that
does
the
invocation
of
the
proper
function
on
the
other
side,
and
when
that
invocation
happens,
any
argument
passed
to
it
or
the
return
value
of
that
invocation
provides
functions.
The
same
principle
applied,
so
you
do
it
in
both
directions.
So,
and
one
one
one
important
detail
before
mark
I
jump
in
is
that
this
function
are
not
identity
based.
So
you
call
the
same
function
twice
with
passing,
an
argument
that
is
a
function.
C
D
Unwrapping:
well
we
don't.
We
don't
do
unwrapping
anymore,
because
if,
if
we,
if
you're
talking
about
I'm
calling
from
the
incubator,
I'm
calling
a
function
that
was
declared
by
eval
previous
eval,
so
it
returns
a
function.
I
get
a
wrapping
of
that
function.
I
call
it
with
passing,
maybe
itself
as
an
argument
to
it.
Okay,
well
you're
going
to
get
a
new
one.
On
the
other
side,
I'm
going.
C
D
C
I
I
You
your
bridge
function
keeps
a
reference
through
your
ethal
to
the
inner
function
once
that
bridge
function
goes
out
of
reach
on
the
incubator
realm
inside.
That
means
your
function
can
be
collected
if
it
was
a
dynamically
created
function,
which
means
anything
else
that
was
in
reach
of
the
function
can
be
collected
and
thus
can
be
observed.
So
you
can
observe
behavior
of
the
incubator
realm
inside
around
the
created.
C
C
Why,
for
example,
the
weak
ref
prototype
does
not
necessarily
have
a
constructor
property
that
points
back
at
the
constructor
things
like
that,
so
yeah.
If
you
can
create
weak
references
or
have
access
to
the
finalization
registry,
you
can
read
a
rather
massive
side
channel
and
and
that's
just
something
we
knew
going
in
when
we
created
weak
references.
C
I
C
C
I
I
D
A
C
It
did
not
open
up
the
side
channel
inter
realm,
and
the
browser
makers
refused
to
implement
that
for
reasons
that
were
understandable,
but
now
that
we're
doing
a
stronger
realm
separation
than
we
had
in
mind
back
then,
perhaps
it's
time
to
revisit
the
side
channel
leakage
between
realms.
I
think
I
want
to
put
that
on
the
table.