►
From YouTube: SES-mtg: Records and Tuples and SES
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).
B
C
B
C
B
Am
the
intro
okay,
very
good,
okay,
so
I'll
I'll
present
reckon
tuple
as
it
stands
right
now
in
the
puzzle,
we
can
talk
about
the
implications
for
ses
and
capabilities
and
all
that.
B
So,
if
you're
not
familiar
with
the
record
tuple
proposal,
it's
a
stage
1
tc39
proposal
to
add
a
couple
of
new
immutable
data
structure,
primitives
to
the
language
specifically
record
and
tuple,
which
are
shaped
like
objects
and
arrays
respectively
records
have
named
properties
and
tuples
have
index
properties
like
like
objects
and
arrays,
respectively,
they're,
similar
in
syntax
to
objects
and
arrays,
except
for
they
have
a
hash
keyword,
and
the
important
distinction
here
is
that
a
record
and
a
tuple
are
primitives
in
javascript.
B
They
are
not
objects,
they
don't
have
identity,
they
are
compared
structurally
and
they're
compared
deeply
and,
most
importantly,
they
are
immutable,
so
records
and
tuples
can
only
contain
primitives
or
other
records
and
tuples.
They
can't
contain
objects.
A
You
said
I
was
the
audio,
I
was
unclear,
did
you
say
they
are
mutable
or
they
are
immutable.
B
Deeply
immutable
deeply
immutable.
Yes,
so
the
proposal
which
I
won't
go
into
every
specific
detail,
especially
ones
that
aren't
specifically.
B
C
D
We've
been
trying
to
stick
with
the
sort
of
value
types,
intellectual
tradition
in
tc39
and
and
I
hope
that
this
can
really
be
the
data
model
that
we
could
eventually
generalize
into
user-defined
types.
If
we
go
that
way,
but
I
think
starting
with
object
and
array
literals
is
the
most
immediately
useful
for
javascript
programmers
right.
B
Yeah
so
like
minor
implementation
details
like
record
and
tuple
they're,
just
like
number
and
string,
they
have
different
type
ofs.
They
are
strictly
different,
primitives
see
whatever
what
other
things
should
I
consider
the
syntax
if
you're
not
familiar
with
it,
it's
been
through
several
iterations.
If
you've
seen
the
initial
proposal
that
was
in
like
last
october,
you'll
notice.
Now
that
the
syntax
is
recursive,
you
must
specify
the
hash
at
every
level.
That's
an
important
update.
A
A
B
It's
simple,
so
the
the
the
case
that
most
stuck
out
to
us
is
that
if
you
are
writing
javascript,
where
you
are
converting
objects
to
records
and
tuples,
if
you
take
or
if
you're,
just
writing
records
and
doing
refactoring
on
existing
code,
if
you
take
a
sub
like
a
like,
if
you
take
a
section
out
of
a
record
in
the
case
where
it
was
recursive,
where
you
didn't
have
to
put
the
hash
at
every
level,
if
you
extracted
it
out
into
a
separate
expression,
it
would
suddenly
become
an
object,
and
it's
not
necessarily
intuitive.
E
I
can
see
another
reason
mark
suppose
that
the
hello
array
here
was
actually
declared
as
a
regular
array.
Instead
of
a
a
tuple,
then
hello
by
implication
is
mutable
and.
D
Requiring
an
earlier
draft
where
it
would
be
implicitly
a
tuple
if
you
just
have
a
hash
around
the
outside,
then
it
would
be
all
the
things
inside
that
are
that,
are
you
know,
curly
brackets
or
square
brackets
would
be
records
and
tuples,
and
you
know
in
some
earlier
drafts
we
actually
had
something
wordier
to
set
off
it
being
a
record
or
tuple
like
const
was
one
thing
that
I
was
pushing
for
that
nobody
seemed
to
really
like
now
that
it's
a
single
character
that
also
sort
of
lightens
the
load
for
including
it
at
every
level.
D
Even
though
we
we
could
make
it
context
sensitive,
but
that
would
it
would
carry
these
other
costs.
I
I
think.
E
One
of
the
benefits
is
that,
with
this
being
explicit,
there's
no
risk
of
confusion
if,
if
it's
a
syntax
error
for
omitting
that
inner
hash
character,
that
makes
it
obvious
hey,
this
is
immutable.
F
Can
I
can,
I
can,
I
know.
D
F
B
Yes,
yeah
and
then
that'll
work
just
as
expected,
and
if
you
for
some
reason,
return
an
object
or
something
from
that
like
expression,
it
would
just
fail
the
type
error
like
if
you
try
to
create
a
record
or
tuple
with
an
object
in
it.
It
will
fail
at
runtime,
okay,.
F
And
is
there
a,
is
there
a
an
operator
to
convert
a
a
an
object
to
a
record
or
an
array
to
a
tuple.
B
Yeah,
so
there
are
there's
a
whole
namespace
appendix
we
have
full
of
library
methods
that
can
do
this.
You
can
pass
it
to
the
record
constructor.
You
can
also
obviously
use
spread
syntax
because
they're
just
enumerable
properties,
okay
and
then
for
tuples.
Similarly,
we
tried
to
model
that
off
of
the
array,
so
you've
got
things
like
array
from
and
array
of.
G
Yeah
yeah,
so
so
yeah
like
if
you
spread
an
object
with
functions
on
it,
though,
with
that
with
that
basically
become
an
error,
or
would
that
just
mean
all
the
properties
that
are
not
objects
on
that?
That
object?
Literal.
B
G
Yeah
so
so
have
you
considered,
though?
Maybe
because
I
mean
the
spread,
syntax
is
kind
of
a
like.
It's
implied
to
be
a
shorthand,
so
so
a
shorthand
can
can
have
a
convenience
aspect
to
it.
I
you
know
it's
just
an
idea
to
consider.
G
Also
syntax,
wise,
double
curly
braces
means
that
you
have
a
distinct
delimiter
on
both
ends.
If
you
are
going
to
need
this
thing,
the
limiter
for
literal
notation,
I
think
you
might
want
to
have
on
the
left
and
right
hand
side.
This
way.
This
way,
it's
it's
unambiguous,
no
matter,
no
matter
where,
in
the
code
you're
looking
just
you
know,
just
brainstorming
ideas
like
like
I'm
not
inclined
to
say
one
way
or
the
other
is
right.
Yeah.
B
No,
this
is
a
that's
a
perfectly
valid
response.
That's
so
that
the
syntax,
especially
whether
or
not
to
include
like
or
just
use
a
different
sigil
for
the
end
of
the
record
or
tuple,
something
that
got
brought
up.
One
of
the
other
alternative
syntaxes
we
investigated
was
this.
I
don't
know
if
you
can
see
it,
I
might
need
to
zoom
in
curly
bar
and
square
bar
syntax,
the
polyfill
and
babel
transform
that
we've
implemented
experimentally
supports
both
of
these
syntaxes
and
it's
similar.
B
It's
not
quite
the
double
curly
or
double
bracket,
but
similar
enough,
we
find
oh
there's
a
long
discussion.
I'd
have
to
find
the
issue
number,
but
there's
a
very
long
discussion
in
the
proposal
repository
in
the
issues
about
the
merits.
You
know
bike
shedding
the
merits
of
the
two
syntaxes
and
there's
a
lot
of
things
to
consider
about
like
editor,
auto,
complete
and
like
ease
of
typing,
and
the
people
have
brought
up
things
like
how
far
away
these
keys
are
on
the
standard,
united
keyboard
stuff.
B
Like
that,
there's
a
lot
of
I'm.
I
like
the
hash
syntax
like
like
for
the
property
that
dan
mentioned.
That
is
a
single
sigil,
but
there's
arguments
for
both.
Like
you
know
it's
it's.
G
D
D
It's
totally
unambiguous
because
they're
different
cases
I
wanted
to
speak
to
the
suggestion
that
object,
spread,
would
maybe
omit
function.
Properties
as
much
as
possible.
We've
been
trying
to
design
this
proposal
so
that
it's
maximally
analogous
to
to
to
objectives
without
without
extra
differences.
G
Or
like
use
of
a
four
dot
spread,
and
that
means
you
know
we
create
a
new
operator
so
yeah,
no,
but
but
maybe
a
record
dot
from
would
that
record.from
would
still
throw
if
there
is
a
function,
maybe
a
record..
You
know
from
something
or
another
another.
G
That
would
basically
just
pick
the
the
fields
that
that
are
not
functions.
D
D
C
I,
like
the
I,
like
the
hash
notation
for
a
different
reason,
is
that
it
has
a
bit
of
a
nostalgic
feel
since,
since
I
believe
brendan
originally
proposed
a
similar
syntax.
Maybe
10
years
ago,
yeah.
H
Yeah,
so
back
to
the
arena,
question
I
think
are
explicit
versus
implicit.
I
do
like
the
implicit
one,
but
I
see
the
value
of
being
explicit.
I
might
open
the
door
for
in
the
future,
doing
some
more
advanced
things
on
the
definition
of
one
of
these
structures.
H
So
I'm
I'm
fine,
it's
a
little
bit
more
typing,
but
I'm
fine
with
that,
but
seems
seems
to
be
safer
to
have
these
implicit
explicit
everywhere
and
then
we
can.
We
can
maneuver
to
a
new
type
of
structure
that
can
match
fine
with
records
and
couples
in
the
future.
A
Yeah
yeah
yeah,
I'm
also
the
the
current
state
of
this
is.
Is
I
like
the
explicitness
when
I
first
saw
it
when
you
first
put
it
up
it
kind
of
shocked
me
because
I
was
used
to
the
other
one,
but
you
know
chip's
question
about.
You
can
put
an
expression
there.
A
It
would
be
very
weird
to
have
an
expression
that
looks
like
an
array
turn
into
a
tuple,
but
an
expression
that
looks
like
a
you
know,
an
expression
that
computes
an
array
that
might
include
an
array
to
have
that
be
rejected
because
it
because
it's
an
expression
that
produces
an
array
rather
than
just
a
literal
array,
would
be
extremely
unpleasant
to
have
that
difference.
A
Right
and
with
regard
to
saul's
question,
I
would
definitely
object
to
any
kind
of
implicit
filtering.
Errors
are
better
for
surprises
than
implicit
behavior.
That
is
not
obvious
to
somebody.
Reading
the
code.
G
Yeah
yeah,
so
so
definitely
a
fair
point.
So
yeah
like
I
just
I
kind
of
want
to
ask
to
understand
and
appreciate
it
so
yeah.
B
Yeah,
so
are
there
any
more
questions
I
I've
kind
of
covered
the
big.
I
think
we've
covered
the
big
parts
of
record
the
main
recognition
proposal,
there's
still
more
for
us
to
cover.
If
we
have
time.
D
We've
been
talking
about
that
and
actually
when,
when,
when
rick
mentioned
destructuring,
it's
something
that
we
don't
have
a
solid
conclusion
on,
because
the
thing
is
that
you
can
use
destructuring
for
normal
objects
and
arrays,
and
it
should
work
like
in
that
example.
The
question
is
whether
we
allow
records
and
doubles
on
the
left-hand
side
for
destructuring
and
the
reason
you
might
want
that
is
so
that
if
you
have
a
arrest,
then
that
would
become
a
record
or
tuple.
D
B
Well,
it
also
the
semantics
get
very
weird,
because
if
you
let's
say
you
have
a
record
that
has
two
keys,
foo
and
bar
foo's,
an
object
bar
is
not,
if
you
destructure
the
foo
but
put
the
bar
in
the
rest,
then
it
will
not.
It
didn't
presume.
You
could
make
the
case
that
it
would
not
throw
because
you're
not
putting
the
object
in
the
record.
It's
in
the
rest
variable,
but
it's
very
it's
like
you're,
conditionally
type
erroring
based
on
which
parts
of
the
object
you
destructure,
which
feels
weird.
A
Okay,
so
I'm
very
glad
that
this
has
both
been
thought
about
well
and
that
it's
been
knitted
from
this
proposal
did
I
gather
that
right
or
is
disturbing.
B
No,
I
mean
you
can
destructure
a
record
into
like
a
an
object
form
of
a
rest
variable,
but
there's
no
syntax
for
adding
a
rest
variable.
That
is
a
record
or
tuple.
A
Okay,
that
that's
what
I
meant
is
the
syntax,
so
I
am
happy
with
it
being
thought
through,
but
omitted.
A
On
the
other
hand,
if
you
feel
like
it's
thought
through
and
there's
and
you're
and
you're
already
prepared
to
take
a
stance
on
a
particular
outcome,
I
would
I
would
also
be
supportive
of
including
it.
I
do
want
to
see
it
eventually.
It's
just
a
question
of
which
one
gets
bundled
into
which
proposal.
B
I
Would
hold
off
on
it
personally,
just
because
I
have
semi
strong
feelings
about
container
types
and
how
destruction
works
right
now,
particularly
with
things
like
promises
and
other
things,
this
likely
will
come
up
again
if
we
get
to
the
boxed
objects
or
boxed
values.
I
So
I
also
had
some
questions.
I
know
on
the
issue
tracker
I've
been
asking
about
prototypes.
I
don't
know
about
your
current
stance,
I'm
still
very,
very
uncomfortable
with
records
having
a
prototype.
D
My
personal
opinion
I
mean,
I
think
we
came
to
agreement
on
the
issue
tracker,
that
tuples
have
to
have
a
prototype
and
unfortunately
it
has
to
be
mutable,
because
we
keep
adding
methods
to
a
rape
prototype
and
we
have
to
be
able
to
add
those
to
tuple
to
monkey
patch
those
onto
double
prototype
in
a
polyfill
over
time.
For.
D
For
records,
I
I
kind
of
feel
like
we
should
have
no
prototype,
I'm
not
convinced
by
the
examples
that
jordan
gave
about
about
that,
but
we
have
this
other
call
with
that
includes
him
tomorrow,
so
that
we
could
talk
through
his
things.
B
I
D
Yeah,
I
agree
with
you
and
further,
I
would
say
it's
an
important
property
of
both
records
and
tuples
that
when
you
access
them
in
sort
of
the
normal
way,
which
is
an
integer
index,
access
for
tuples
and
a
and
a
or
at
least
an
integer
index
access,
that's
in
range
for
tuples
and
for
records.
It's
it's
any
property
access.
B
I
One
thing
that
this
comes
up
with
is:
does
that
mean
the
instance
of
works
on
tuples,
but
not
on
records
if
it's
null.
A
When
you
say
broken,
I
mean
there's
a.
There
is
a
consistent.
There
is
a
a
behavior
for
primitives,
that's
very
consistent
in
the
spec,
as
it
is
today
that
I'm
assuming
we're
extending
to
this,
which
is
the
primitive
itself,
has
no
prototype,
but
rather
the
code
in
which
a
property
accessed
on
the
primitive
is
expressed
that
the
first
step
of
that
property
access
of
basically
the
property
access
on
a
primitive
turns
into
a
property
access
on
the
corresponding
primordial
prototype.
A
Yeah
and
the
the
exact
the
wrapper
object,
that's
created
just
implicitly
in
order
to
do
the
dot
access
is
not
actually
observable.
D
F
E
D
That,
but
I
think
it's
important
for
records
that
if
you
just
write
a
property
that
doesn't
exist,
it
shouldn't
like
create
a
wrapper
and
then
add
it
to
the
wrapper
and
then
the
whole
thing
gets
thrown
away.
I
think
that
would
be
very
weird.
So,
overall,
they
look
kind
of
like
string
string
wrappers,
but
they
have
this
extra.
A
Okay,
that
is
interesting,
certainly
will
require,
thought
I
mean
yeah,
I'm
sure
you
guys
have
thought
about
it,
but
I
I
I
need
to
think
about
it
as
well.
I
have
not.
It
is
certainly
different
than
the
precedent,
but
I
understand
the
motivation
for
it.
B
E
I
have
one
small
thing
sure
I'm
not
sure
I
really
like
parse
immutable
for
a
couple
of
reasons
and
I'm
talking
about
the
concept
of
parse
immutable.
That's
mentioned
in
the
main
document.
B
D
A
E
My
objection
is
minor,
but
it
is
the
fact
that
if
you
do
a
json.parse
number
one,
you
have
the
reviver
argument
of
json.parse.
The
second
argument,
which
not
a
lot
of
people,
know
about
number
two
pars
immutable
could
really
just
be
a
couple
of
a
couple
of
calls.
You
have
json
parse,
wrapped
in
a
record
dot
from
or
whatever
the
equivalent
is,
a
conversion
from
a
json
parse
output
into
a
record
or
a
tuple
is
what
I'm
getting
at.
B
C
There's
very
likely
to
be
performance
implications
for
engines
that
are
optimized
for
records
and
tuples
and
parse
immutable
would
be
having
parse
immutable
would
result
in
a
much
much
more
yeah.
F
F
Actually
you
just
want
to
substitute
json.parse
immutable,
yeah
and
being
able
to
drop
being
able
to
do
a
simple
edit
in
line
being
able
to
have
an
optimized
execution
that
didn't
go
through
this
intermediate
translation
and
conversion
phase.
I
think
that's
a
win.
E
G
D
E
G
D
Give
a
context
about
json
and
records
and
tuples
one
frequent
performance
issue
that
sometimes
is
raised
to
js
engines.
Maybe
they
should
solve
it
magically
is
the
performance
of
json.parse
of
json.stringify.
I
was
like.
Why
would
you
do
that?
Well,
it's
a
sort
of
deep
clone
mechanism,
but
only
for
this
certain
subset.
D
Why
would
you
do
deep
clone
well
about
a
lot
of
programs,
keep
track
of
their
current
state
in
terms
of
things
that
can
be
serialized
into
json
so
that
it
can
be
cloned
this
way,
and
so
they,
then
they
can
make
manipulations
as
the
program
runs.
D
This
is
all
very
weird
records
and
tuples
removes
the
need
for
such
a
for
such
a
clone
because
it
provides
the
db
mutability
and
I
was
actually
I
shouldn't
have
been
surprised,
but
I
was
kind
of
surprised
when
talking
to
javascript
application
developers,
how
well-known
the
hazards
of
lack
of
deep
immutability
is.
It
got
very
easy
buy-in
from
javascript
developers
these
days
because
they
face
these
problems
of
accidentally
mutating
something
so.
D
Yes
and
they
run
into
problems
with
it
all
the
time,
because
they
forget
to
freeze
at
some
point
or
you
know
they
only
turn
it
on
in
debug
mode,
because
it
has
runtime
costs.
D
B
B
Recursive
freeze,
especially
not
just
a
recursive
freeze
for
object.freeze,
but
like
all
there
are
a
lot
of
one
of
the
key
things
we
mentioned
in
our
like
research,
is
that
all
of
the
userland
immutable
data
structure
libraries
have
this
problem
where
these
immutable
data
structures
can
contain
mutable
objects
and
the
boundary
between
them
is
sometimes
loose
and
hard
to
find,
and
so
you
end
up
writing
a
lot
of
code.
That
checks
is
this
the
mutable
version,
or
is
this
the
mutable
version?
B
B
We
have
not
looked,
we
have
not
done
the
same
level
of
digging
the
the
libraries
I'm
referring
to
specifically
are
like
immutable
js
and
mr
and
the
related
like.
G
And
I
think
react
react.
Also
react.
State
is
one
of
those
places
where
they
give
you
a
set
state
method,
and
then
they
do
their
mojo
and
you
know
yeah,
so
so,
just
about
person
mutable
one
last
just
clarification,
I
guess
what
would
a
reviver
argument
mean
in
that
context,
just
just
for
for
people
to
kind
of
like
if
they
come
up
with
ideas?
That
would
be
nice,
because
I
mean
it's
clear
when
you
want
to
recon
reconstruct
serialized
state.
B
That's
a
good
question,
I'm
not
exactly
sure
I
mean
I
don't
know
what
would
be
different,
I
mean
you
could
you
would
revive
them
to
like?
I.
E
E
I
I
have
a
funny
feeling
that
you
might
want
to
exclude
reviver
in
this
case,
for
now
at
least
early
on.
Definitely,
you
want
to
file
a
ticket
on
it,
but
I
think
early
on,
you
may
just
not
want
to
support
a
reviver
for
this,
just
because
it
adds
more
possibility
of
things
going
wrong.
C
D
H
Question
question
about
the
parts
I
I
noticed
that
stringified
is
not
there
and
I'm
curious
about
why.
A
A
One
is
where
the
underlying
implementation
is
able
to
share
pointers,
in
which
case
these
things
are
are
not
just
independent
of
realm
they're,
actually
independent
of
agent,
depending
on
how
you
implement
them,
of
course,
but
they
should
be
independent
of
agent,
so
you
should
be
able
to
share
them
between
processes
that
are
in
the
same
address
space
by
direct
pointer
sharing.
D
So
a
case
that
this
comes
up
in
for
implementations,
for
direct
pointer
sharing
is
on
the
web
with
workers,
and
so
the
interface
that
you
would
use
to
transmit
a
record
or
tuple
to
a
worker
would
be
postmessage.
D
So
there's
a
there's
a
segment
of
this,
which
is
integrating
post
message.
You
know
integrating
html,
serialization
and
deserialization
to
records
and
tuples.
That's
pretty
trivial
and
the
spectacs
just
looks
like
copying
it
basically
about
whether
they
would
actually
use
direct
pointer
sharing.
My
understanding
is
sometimes
they
might
sometimes
they
wouldn't.
Probably
the
initial
implementations
would
be
copying.
D
Some
some
javascript
engines
have
multi-threaded
heaps
and
some
really
don't
have
multi-threaded
heaps
right.
Yeah.
C
D
There's
a
lot
of
stuff
with
records
and
tuples,
where
you
might
where
you
would
really
want
good
performance,
so
you
would
want
performance
when
sharing
between
workers.
You
would
want
performance
also
when
doing
a
modification
with
a
spread,
either
adding
elements
or
placing
elements.
You
might
expect
that
it
have
a
kind
of
rope-like
treatment
like
strings,
sometimes
do
and
didn't
thought
about
that.
D
This
proposal
is
to
guarantee
that
implementations
can
perform
such
optimizations
to
make
them
unobservable,
but
to
be
clear
in
communication
with
javascript
developers
that
they
can't
expect
that
they'll
always
be
there.
D
Another
optimization
like
this
is
is
comparison
with
with
triple
equals
or
any
of
the
comparison
operators
they're
all
the
same
for
records
and
tuples
that
it
would
be
valid
for
implementations
to
do
hash,
considering
and
they're
definitely
not
required
to,
and
it's
unobservable
whether
or
not
they
do.
H
So
daniel
the
the
second
part
of
the
question
is
so
we
we
went
from
rom
to
round
to
process
to
process,
and
now
we
go
over
the
network
and
it
specifically
on
on
server-side
rendering,
which
is
becoming
even
more
popular,
and
even
the
engines
are
implementing
something
like
a
potential
shadow,
dom
shadow
root,
clarity,
shadow
root
and
such
is
it
going
to
be
possible
if
I'm
rendering
the
page
on
the
server
side
being
able
to
send
some
of
these
structures
down
to
the
client
in
a
satellite
way,
without
having
to
do
some.
H
Engines
are
nowadays
there's
a
sense
of
what
this
server-side.
Rendering
is
a
thing
that
is
important
for
some
people,
just
just
to
highlight
that,
but
not
necessarily
related
to
what
I'm
asking
the
question
is
whether
or
not
I
will
be
able
to
run
some
code
on
the
server
side
that
use
some
javascript,
that
does
some
serialization
and
send
those
structures
to
the
client
side
to
be
used.
H
B
H
A
So
let
me
anybody
who's
doing
this
today
and
wants
a
high
fidelity
copying
of
what
one
would
normally
think
of.
As
json
data
they're
trying
to
do
high
fidelity.
They
already
have
a
problem
with
with
nan
and
infinities
and
undefined.
A
Let's
just
take
nan
in
infinities
and
you
could
you
could
say
that
undefined
should
not
be
included,
but
having
floating
point
not
be
able
to
transfer
nan's
infinity
is
really
irritating.
So
at
agoric
we
want
both
high
fidelity
and
we
want
it
to
include
a
lot
more
pass
by
copy
than
jason
directly
represents.
A
A
That
over
here
should
go
something
that
is
decoded.
You
know,
decoded
to
a
nan
or
decoded
to
an
infinity,
will
decodable
something
so
there's
some
kind
of
you
know
special
convention
that
normal
objects
are
supposed
to
avoid
that
the
serialization
can
make
sure
it
does
not
appear
on
the
input.
A
A
G
So
so
I
I
had
one
thing
come
to
mind
when,
when
this
discussion
was
happening,
is
basically
how
do
I
go
from
an
object
that
has
deep
in
it
some
records
and
tuples
and
then
end
up
with
a
string
and
take
that
elsewhere
and
basically
generate
that
same
structure?
I
know
I
know
that
you
might
use
a
particular
contextual,
serialized
deserialize
or
on
serialize,
but
it
just
feels
to
me
that
until
we
we
talked
about
this
json
was
very
clear.
You
get
an
object
now
we're
saying
we're.
A
Many
uses
of
json
are
just
limited
to
direct
usage
of
what
you
can
represent
in
json
and
though,
and
those
uses
you
only
have
objects
and
and
arrays
and
primitive
data
that
does
not
include
undefined
does
not
include
nan
does
not
include
infinities,
it
does
not
include
bigot,
so
so
that's
certainly
a
usage
of
json
and,
if
already
being
limited
to
not
being
able
to
represent
floating
point,
infinities
makes
it
clear
how
limited
it
is,
but
it
probably
is
by
far
the
vast
majority
of
use
of
json.
A
D
Yeah,
I
really
think
there's
room
for
a
separate
orthogonal
proposal
here.
I
keep
hearing
future
requests
for
this.
It
was
really
the
number
one
feature
request
for
big
end.
I
want
to
put
big
end
on
json
and
I
would
explain
to
people
you
do
this
encoding
thing.
Everybody
says,
oh,
that's
so
annoying
can
I
like
convert
it
to
it.
H
D
G
I
I
think
what
what
people
get
hung
in
is.
Is
this
idea
that
when
you
have
a
standard
way
of
doing
things,
it
is
a
universal
way
to
exchange,
but
once
once
you
start
putting
like
opinions,
unfortunately
end
up
with
whoever
can
muscle
their
opinion
if
there
will
become
sort
of
a
convention
and
and
and
these
things
tend
to
create
more
more
bugs.
G
You
know
when,
when,
when
you
have
more
than
one
opinion
kind
of
like
acting
as
if
they
made
an
argument,
why
they're
better
but
they're,
really
just
making
an
argument
on
why
they're
bigger
right?
I.
G
A
I
don't
think
there's
any
wiggle
room
on
this
one.
If
jason
itself
is
simply
not
going
to
change
period,
it
will
never
be
able
to
have
a
direct
representation
of
nands
and
infinities,
and
that
means
that
there
must
be
an
encoding
to
be
high
fidelity,
and
I
think
the
right
answer
to
what's
being
raised
here
is
to
have
a
winner
among
the
encodings,
in
the
sense
of
some
rising
to
become
the
de
facto
and
eventually
de
joure
standard,
supported
by
libraries
and
may
be
eventually
even
supported
by
some
further
function
in
the
language.
F
So
so
this
is,
this
is
a
complete
digression,
but
opportune
point
to
mention
it,
which
is.
I
am.
I
have
a
sort
of
back
burner
project
which
is
which
is
working
out
an
api
for
for
doing
exactly
this
to
to
handle
the
encoding
of
different
things,
something
that's
a
little
bit
more
ergonomic
than
the
the
reviver
mechanism.
F
F
F
D
H
Erase
it
just
because,
but
I
I
work
initially
and
serialized
javascript,
which
is
a
very
popular
library,
we
did
it
at
yahoo
many
years
ago.
It
has
like
more
than
10
million
downloads
per
week,
and
and
and
it
does,
the
things
that
mark
was
explaining.
He
does
all
that
just
wanted
to
make
sure
that
I
get
the
right
semantics
around.
A
Okay,
so.
D
H
I
think
I
think
it
would
be
possible
yeah.
I
think
it
would
be
possible
that
a
library
like
that
will
be
able
to
serialize
when
very
popular
on
server-side
rendering.
So
you
do
your
operations
and
then
you
serialize
something
to
the
client
that
gets
evaluated
at
javascript,
not
parsed.
It
just
gets
evaluated
on
the
client
side.
D
E
D
Long
discussion,
so
it
the
reason
is
well
one
important
thing
about
records.
Is
that
they're
order
independent?
So
if
you
have
a
record
with
a
a1
b2,
that's
the
same
record
as
with
b1
b2
a1,
and
you
know
we
have
to
make
a
well-defined
four
in
order
or
well-defined.
You
know:
object.keys
reflect.keys
order,
own
keys,
so.
D
D
F
D
Oh
sorry,
no,
I
can't,
I
can't
remember
I
guess
we
can
go
into
the
other
ones.
A
You
support
computed
the
computed
property
names.
I
B
Yeah,
okay,
yeah,
and
if
you
it
got
mentioned
by
someone
recently,
we
would
probably
just
use
instead
of
two
property
key.
We
use
tostring,
which
throws
on
symbol.
So
if
you
use
a
computed
property
key,
that
is
a
symbol,
it
would
just
throw
a
type
error:
good,
yeah,
okay,
so
yeah
that
we
can
dan
feel
free
to
interrupt
me
whenever,
when
you
remember
what
you
were
thinking
of,
but
we
can
move
on
to
some
of
our
related
complementary
proposals.
B
B
See
if
I
can
remember
the
url,
yeah
so
deep
prep,
so
we
created
a
couple
of
complimentary
proposals
to
kind
of
solve.
Some
of
the
ergonomic
I
wouldn't
say
concerns
because
we
think
that
the
mvp
is
com
or
the
recognition
base
proposal
is
complete
and
valuable
without
it,
but
we're
actually
debating
moving
deep
properties
into
the
proposal
itself,
so
d-pap.
So
one
of
the
ergonomic.
B
I
guess
you
could
say
problems
with
record
and
tuple.
Is
that
because
they're
immutable,
you
can't
easily
change
the
values
in
them
or
can't
easily
create
a
new
record
with
copy
values.
If
the
record
is
deeply
nested
because
spread
only
works
at
one
level,
so
we
are
proposing
an
additional
spread
syntax
that
if
I
can
find
it
on
this
page,
I
think
you
would.
B
Did
was
it
right
at
the
top?
I
skipped
it.
Oh
yeah,
it
totally
was.
This
is
the
example
I
was
thinking
of
where
you
could
describe
nested
properties
that
will
be
updated
in
the
resulting
record
or
tuple
via
traditional
spread
syntax.
B
This
is
pretty
much
the
whole
example.
It's
pretty
succinct
we're
considering
moving
this
into
the
main
proposal
repository
because
it's
rel
other
than
the
syntax
cost.
It's
relatively
low
impact
semantic
wise
just
for
record
object.
It
gets
a
lot
more
complicated.
We
haven't
figured
out
what
we're
currently
specifying.
This
is
not
possible
for
for
objects
themselves.
A
I
I
would
find
that
unfortunate.
I
think
that
it
has
just
as
much
value
for
objects,
and
I
think
the
non-uniformity
of
having
this
work
in
records
and
tuples
and
not
objects
and
arrays
would
really
be
not
good.
I
mean
to
have
something
work
in
one
and
not
the
other
when
there's
an
obvious
semantic
reason.
Why
they're
just
different
that
I
could
understand
and
explain,
but
in
this
case
so
there's
no
reason.
Maybe.
D
D
You
know,
if
you,
for,
for
both
a
record
and
a
tuple,
the
identity
spread
returns
the
same
value.
This
isn't
the
case
for
objects,
objects
have
all
kinds
of
other
stuff
going
on.
They
have
prototypes.
They
have
internal
thoughts
of.
D
The
identity
object,
spread
or
the
identity
array
spread.
You
don't
just
get
something
that
has
a
different
identity.
You
get
something
that
may
be
different
in
all
sorts
of
other
ways,
and
so
I
felt
like
it
would
be
weird
to
have
this
syntax.
That
just
implicitly
does
all
these
identity,
but
overriding
one
part
spreads
for
objects
and
arrays.
A
So
I
think
that.
A
I
think
that
that
the
implication
is
that
it
does
do
the
conversion
as
deeply
as
the
syntax
that
you're
using
the
you
know
the
the
destructuring
syntax.
That
only
has
a
a
rest
and
nothing
else
is
not
doing
identity
thing
expression
is
doing
only
spread
and
nothing
else
is
not
doing
identity
in
both
cases.
On
the
object
side,
it's
doing
a
copy
with
all
the
conversion
that
you're
talking
about.
A
D
I
think
I
still
think
it's
pretty
surprising
when
you
see
a
quick
path
like
this,
you
don't
think,
and
you
and
you
see
a
spread.
The
spread
should
be
the
part.
That's
copying
the
object,
but
the
spread
is
only
doing
a
shallow
copy
of
the
object
it
doesn't.
When
you
see
the
path.
The
path
is,
what
will
call
for
this
object
to
be
kind
of
mutilated
and
treated
in
only
its
shallow
form?
That
to
me
feels
very
non-local.
H
The
first
one
is
that
I
I
feel
that
we
should
focus
on
the
mvp
rather
than
adding
things
that
could
be
added
later
on,
just
just
for
the
sake
of
moving
forward,
not
having
controversy
around
it
and
the
other
part
of
it
seems
very
straightforward.
This
one
is
a
little
bit
complicated.
The
second
common
is
that
isn't
this
a
foot
gone
in
in
a
sense
like
it's
really
easy
to
mess
up,
and
maybe
mistype
one
of
the
path
and
what
happened
there
right?
H
You
do
the
incorrect
path
to
the
object.
I
mean
to
the
to
the
tuple
that
you're
looking
for
or
something
like
that,
what
happened
there?
I
don't
think
it's
quite
the
same
as
doing
it
explicitly
one
by
one
in
the
structuring
pattern,
but
it
might
be
that
I'm
wrong
here,
but
it
feels
to
me
that
is
probably
moving
this
to
phase
two.
H
B
Together,
I
could
see
the
argument
from
the
perspective
of
there
are
a
lot
of
tricky
edge
cases
and
we
there
that
are
controversial.
But
I
would
argue
that
from
an
ergonomics
like
syntax
complexity
like
this
is
too
much
to
push
on
the
user.
It's
this
or
like
the
talking
about
like
mistyping
paths,
our
exam
or
our
our
demonstrations
are
that
the
there's
much
less
of
a
chance
of
that
happening
because
there's
way
less
code
on
the
screen,
like
it's
a
way
more
ergonomic
and
terse
way
of
describing
the
same
computation
like
this.
B
This
d-path
spread
here
is
functionally
equivalent
of
this,
but
you
have
to
specify
the
state
one
identifier,
many
more
times
so,
if
you're
arguing.
H
D
H
Again,
I
might
be
missing
something
here
like
if
I,
if
the,
if
you're
destructuring
state
one
there
like
you
destruct
that
and
inside
I
mean
in
this
case
it's
on
only
one
level.
Let's
assume
there
is
more
more
than
one
level
there,
but
if
you're
destructing
that
and
you're
specifying
certain
bits
that
you
want
to
flip,
but
the
path
that
you're
using
does
not
exist
on
the
original.
D
H
D
A
Okay,
let's
take
the
state
two,
that's
on
the
board.
Whoever
is
projecting.
Can
you
just
copy
that
definition
of
state
two
into
an
editor.
A
Yeah,
it
just
is
perfect,
so
we
can
get
the
the
syntax
highlighting
back
if
we
wanted.
Okay
now
the
the
count,
the
line.
Three,
that's
a
three
level
deep
path,
correct.
B
A
Okay,
so
on
line
two
after
the
triple
dot
and
before
the
state
one,
I
want
you
to
type
open,
curly,
dot,
dot,
dot,
open,
curly,
dot,
dot
dot
and
then,
on
the
other
side,
do
the
closing
curls,
okay,
the
I
would
so.
My
suggestion
is
that
if
you
want
whatever
your
deepest
path,
is
you
have
to
do
that
dot,
dot,
dot,
nesting
on
the
at
the
dot,
dot,
dot,
site
and
notice
that
it
has.
It
expresses
exactly
the
semantics
that
if
implicit
would
be
surprising,
it
converts
state
one
to
an
object.
A
It
can
it
and
then
it
converts
it.
You
know
into
a
flat
object:
it
converts
it
to
a
flat
object
again
and
then,
finally,
it
it
spreads
the
flat
object.
So
at
that
point,
the
the
it's
clear
that
three
levels,
deep
you're
operating
not
on
some
original
object
in
the
spread
of
state.
A
No,
it
doesn't.
Okay,
I'm.
D
E
B
A
H
Yeah
just
again,
I
feel
that
all
these
could
be
phase
two
kind
of
proposal
like
once
we
have
the
mvp.
We
will
go
back
and
we
improve
over
this
one.
It
should
be
easy.
D
I
want
to
explain
the
reason
that
I've
been
encouraging
investigation
into
both
these
deep
paths
and
then
this
box
proposal
that
we'll
probably
talk
about
next.
The
reason
is
because
when
we
presented
records
and
tuples
to
people,
these
were
the
concerns
that
people
raised.
How
do
you
do
these
deep
updates?
That's
that's
a
major
regression
that
you
have
from
mutable
data
structures
and
then
how
do
you
point
to
objects?
D
The
the
goal
of
these
proposals
is
to
constructively
respond
to
those
concerns,
so
we
can
decide
to
do
them
later,
but
I
do
think
that
it's
worthwhile
for
us
to
think
them
to
think
them
through
to
make
sure
that
we
have
a
good
sort
of
general
direction
forward.
B
Yeah
and
in
terms
like
we're,
not
this
isn't
merged
into
the
main
proposal.
Yet
it's
a
topic
that
we're
actually
going
to
discuss
during
the
june
update
we're
going
to
bring
it
up,
bring
it
to
the
committee
for
more
investigation,
because
during
the
last
update
there
were
several
committee
members
that
mentioned
during
that
during
that
meeting
that
they
would
like
to
see
this
merged
into
the
main
proposal
when
we
showed
it
at
stage
zero.
But
I
very
much
appreciate
the
feedback
that
maybe
it
shouldn't
like.
C
I
love
that
this
explores
like
second
and
third
order
effects
of
a
proposal
for
a
language
feature.
I
I
think
that
it's
ev
every
language
feature
especially
syntactic
ones
like
this,
have
implications
what
people
are
going
to
think
of
after
this
becomes
reality.
Well,
why
didn't?
We
also
do
this.
At
least
that
would
be
consistent
that
and
then
you
know,
and
then
okay
now
we're
in
that
world,
and
then
these
ideas
would
be
consistent.
C
B
Right
I
mean
a
lot
of
this-
is
that
we've
received
an
like
an
outstanding
amount
of
community
feedback
about
this,
and
there's
been
a
lot
of
people
that
have
played
with
it
in
the
playground
that
want
to
provide
feedback
on
the
ergonomics
before
it
lands
as
an
orthogonal
feature
in
the
language.
So
yeah,
exactly
echoing
that
thought.
C
Yeah
and
and
having
records
and
tuples
is
part
of
a,
as
I
recall,
a
larger
vision
that
has
for
value
types
in
general
and
having
that
fully
explored
before
committing
seems
like
a
good
idea
too.
D
C
Yeah,
I
have
a
question
on
the
on
the
gist
that
we
have
in
front
of
us.
I
and
again
I
apologize.
I
haven't,
read
the
the
deep
path
proposal.
What
is
what
is
the
implication
of
having
on
say
introducing
a
line
between
two
and
three
where
you
state
that
counters
is,
is
a
tuple
of
with
values,
zero
and
one.
D
B
D
B
C
All
right
is
so.
My
question
is
basically
is
like
each
property
each
each
each.
Each
each
clause
that
you
introduce
into
the
in
this
comma
limited
list
of
the
record
declaration.
Is
that
implying
a
merge
with
the
state
implied
by
everything
that
preceded
it.
D
D
C
So
if,
if
online,
if
now
between
with
the
state
as
it
is,
if
you,
if
between
line
three
and
four
you
said
counters
colon
and
then
another
array
or
actually
a
more
more
illustrative
example,
is
between
lines.
Five
and
six.
If
you
then
said
counters
is,
let's
just
say,
the
string
gotcha,
the
result
would
be
just
having
the
field
counters,
with
the
string,
gotcha
and
everything
before
all
of
the
counters
manipulations
before
would
be
discarded.
H
B
Okay,
if
there's
no
other
topics
or
discussion
on
the
d-path
properties,
I
I.
E
Do
want
to
go
back
to
record
and
tuple
for
a
moment
sure,
and
I
want
to
keep
it
short.
No
more
than
five
minutes.
I
did
notice
something
I
just
realized
something.
The
names
record
in
tuple
are
likely
to
collide
with
user
space.
E
B
E
Is
simple
that
we
renamed
the
suit
immutable
record,
an
immutable
tuple.
B
I
haven't
done
a
deep
web
compatibility
dive
yet,
but
for
my
initial
investigation,
that's
not
the
case.
The
only
user,
land
library,
that's
like
popular
enough
in
the
immutable
space,
especially
to
do
this
doesn't
assign
like,
doesn't
create
these
globals
their
namespace
under
the
like
under
the
module.
The
other
conflicts
something
to
consider
I'll
bring
it
up
is
that
there
is
a
typescript
built-in
type
called
record.
It's
not
a
conflict
per
se,
because
there's
no
syntax
ambiguity
there.
You
know
one
is
type
space.
B
One
is
in
value
space
we're.
We
we've
talked
a
little
bit
with
typescript
to
figure
out
what
to
do
there.
They're,
not
they
don't
seem
to
be
like
concerned
on
like
blocking
the
proposal
on
that,
but
it
might
just
require
some
education
on
the
typescript
side.
We
can
help
with
that
to
like
figure
out
how
to
describe
people.
These
are
different,
maybe
a
flag
somewhere.
B
The
other
conflict
is
at
the
spec
level
and
at
the
web
idl
spec
level,
because
there
is
a
specification
level
record,
but
this
is
mostly
an
editorial
problem
and
a
few
different
people
have
expressed
to
the
opinion
that
it
doesn't
look
like
the
the
right.
The
specification
of
a
record
isn't
important
compared
to
the
runtime
level.
B
Yeah
no,
this
is
extremely
valuable.
It's
it's
important.
It's
you
know
we
I
if
it
ends
up
being
called
record
and
we
have
to
rename
all
these
instances
of
the
specification
level
record
in
the
language.
I
will
volunteer
to
do
a
lot
of
that
work,
because
I
would
feel
very
sorry
if
the
changes
we
added
made,
someone
do
all
that.
D
Great,
so,
if
we're
back
to
records
and
temples,
there's
a
core
api
design
question
that
I
wanted
to
pose
to
you,
which
is
for
things
like
nan
and
negative
zero.
There's
the
question
of
what
do
you
do
with
you
know?
Is
it
the
same?
Not?
Is
it
the
same
record
or
temple,
because
it
it's
observably
different
object
that
is,
will
be
different,
but
for
double
equals
and
triple
equals?
Should
things
be
triple
equals
if
they're
they
should
a
tuple
containing
nan?
D
The
the
current
place
that
we
landed
on
is
this
was
not.
This
is
not
an
awesome
thing
to
make
these
special
values
and
there's
probably
a
bunch
of
code
that
expects
that
nan
and
you
know,
plus
and
minus
zero,
are
the
only
values
in
javascript
that
that
actually
operates
so
weirdly.
When
it
comes
to
triple
equals,
it
would
be
great
to
not
expand
that
set.
D
So
the
idea
is
that,
as
you
can
see
here,
a
tuple
containing
nan
triple
equal
is
the
same
as
the
the
tuple
containing
nand,
but
it
all
striply
equals
it
and
negative
zero
and
positive
zero
are
not
neither
are
they
the
same
value.
Nor
do
they
double
equals
or
triple
equals.
So.
C
D
C
Well,
my
feelings
are
confused,
but
the
I
think
the
way
the
way
to
look
at
this
is
to
answer
questions
about
what
you
need
from
equality
and
triple
equality,
because
those
the
what
you
need
seems
to
be
what
motivates
us
to
have
different
answers
to
that
question
in
various
contexts,
but
because
these
are
a
value
type.
I
assume
I
won't
assume
so
one
question
is:
do
you
intend
for
these
things
these
to
be
used
as
keys
in
a
map
or
possibly
a
weak
map?.
C
Oh
yeah,
so
it
would
be
that's
right.
Okay,
cool
good
answers
both
and
because,
because
you
need
them
to
be
suitable
as
keys
in
a
map,
it's
necessary
for
identical
keys
to
be
usable
to
retrieve
the
same
exact
value
again
there
should
be.
There
should
be.
No.
There
should
be
no
case
where
you
can
use
a
a
value
to
add
something
to
a
mapper
set
and
then
not
be
able
to
retrieve
it
again
with
the
exact
same
key
right.
A
D
A
Yeah
another
thing
that
that
just
sort
of
falls
out
from
this
that's
very
pleasant
is
whenever
our
almost
every
time
I
write
triple
equals.
I'd
say
you
know
like
98
at
least
I
would
have
rather
said
object.
A
Dot
is,
except
that
it's
more
awkward
to
type
the
over
here
you
can,
where
you
would
have
said
object
dot
is
you
can
instead
say
sharp
open
bracket,
whatever
you
know,
triple
equals
sharp
open
bracket
whatever
so
by
just
square
brackets,
so
by
just
doing
singleton
tuples
on
both
sides,
you
have
a
syntactically
pleasant
way
of
getting
the
object.
That
is
semantics.
A
So
yeah,
whether
you
like
it
or
not,
this
that
would
be
a
consequence
of
this
proposal
and
I
think
some
people
would
like
it.
I
think
maybe
I
would
like
it
in
any
case
good.
A
So
the
the
answer
is
for
all
four
of
these
javascript
equality
operations
when
it
recurs
it's
doing
only
object.
Dot
is
deeply.
Is
that
that
the
the
outcome
exactly
okay,
good.
B
G
Interesting
part
of
what
mark
just
brought
up
is
actually
to
me
that
it
exposes
at
a
syntactic
level
the
the
same,
the
object,
that
is
machinery
in
a
way
that
doesn't
exist
right
now,.
D
D
A
B
Yeah
yeah
yeah,
so
we'll,
okay,
so
boxing
this
is
a
large
problem
space,
but
I'll
just
go
through
top
to
bottom,
so
record
and
tuple.
One
of
the
key
goals
is
to
have
deep
immutability
guarantees.
So
you
can't,
if
you
try
to
put
an
object
or
a
function
or
whatever
inside
of
a
record
or
tuple
it'll,
throw
a
type
error
and
one
of
the
key
reasons
we
did.
That
is
for
one
for
just
ambiguity
and
ergonomics.
B
It
was
a
commonly
requested
or
commonly
mentioned
sharp
edge
when
using
user
land
immutable
libraries,
and
so
it
provides
alongside
all
the
primitives
and
the
pureness
and
all
that
stuff.
It
provides
some
nice
guarantees
that
programmers
will
or
tell
me
that
they
would
enjoy.
B
It's
totally
fine,
no
you're,
not
no
yeah
totally.
What
was
I
saying?
Oh
okay,
so
even
with
that
key
goal
of
being
immutable,
people
would
like
to
be
able
to
express
or
like
point
to
things
that
are
immutable
or
like
have
want
to
have
the
opt-in
ability
to
point
to
some
external
structure
that
isn't
immutable,
and
there
are
a
few
cases
in
which
you'd
want
to
do
that.
B
You
know,
for
example,
if
you
want
to
attach
a
method
to
an
object,
you
can
just
do
that.
Enclosure
wrap
the
object
and
do
whatever
you
want,
but
in
a
record
you
could,
for
example,
store
that
state
you
needed
in
the
object
on
the
record
itself
and
then
have
some
external
function.
You
call
you
know
with
like
an
action.
B
You
can
do
something
like
that.
It's
very
trivial
example.
You
can
do
the
identity
spread
to
copy
the
properties
of
an
object
into
a
new
record
that
you
then
use
inside
that
record
so
that
you
just
make
a
copy
of
the
object
where
needed.
Instead
of
storing
the
object
directly
and
getting
a
type
error,
there
are
some
more
advanced
use
cases
where
you
might
want
to
keep
track
of
a
set
of
references
for
a
given
structure
that
you
might
want
to
swap
in
and
out.
B
The
common
refrain
on
in
the
community,
and
sometimes
in
the
committee,
is
something
like
a
virtual
dom
where
you
have
some
virtual
structure.
That
represents
a
document
that
is
static,
that
is
comprised
of
records
and
tuples,
and
then
you
have
slots
or
holes
or
something
similar
that
you
slot
these
mutable
references
into,
and
you
might
you
you
can
accomplish
with
this,
mostly
with
user
land
by
creating
some
wrapper
that
generates.
B
You
know,
uses
primitives
to
like
indicate
holes
in
the
structure
via
like
numbers,
or
you
can
use
symbols
and
their
identity
to
do
that.
To
like
have
these
references
you
can
abstract
that
out
into
a
class
that
you
know,
does
all
this
for
you
and
takes
care
of
a
lot
of
this
machinery,
and
then
you
know
it's
just
like
a
a
bit
of
code
to
de-reference
these.
You
know
some
external
map,
that's
all
trivial,
you
can.
You
know
yeah.
A
Yeah,
I
want
to
point
out
that
that
a
virtue
of
this
that's
not
necessarily
obvious,
is
that
you
can
only
dereference
if
you
have
a
thing
to
use
to
look
it
up.
So
from
a
capability
perspective,
the
structure
itself
doesn't
carry
the
mutability
right.
You
have
to
already
have
shared
access
to
the
mutability
in
order
to
look
up
and
among
two
things
that
don't
have
shared
access
to
common
mutability,
they
still
don't
have
a
communications
channel.
B
Right
exactly
yeah,
that's
a
really
good
point.
So
these
though
so
we
we,
I
the
all
of
these
user
link
solutions
we
think,
are
really
valuable
and
cover
90
of
the
use
case.
B
Especially
there
have
been
a
lot
of
people
that
have
talked
about
templating
these
records
and
tuples
via
this
like
bookkeeping
strategy,
and
we
think
this
is
this
user
land
solution
is
more
than
sufficient
for
most
of
those
use
cases,
but
there
are
some,
I
will
say
it
again-
sharp
edges
with
this
around
memory
management,
because
if
you
have
a
nested
record
or
tuple
that
has
some
like
array
indices
and
some
you
know
external
reference
bookkeeping
system,
then
the
lifetime
of
those
referenced
objects
is
dependent,
presumably
on
the
bookkeeper
itself.
B
So
if
you
have
to
manually
keep
track
of
all
that
it
becomes
tedious.
You
have
to
manually
create
these
references
using
this
external
object
and
it
gets.
You
know,
there's
a
lot
of
boilerplate
involved
in
making
this
all
work.
D
In
particular,
the
the
ref
bookkeeper
or
the
template
thing
only
makes
sense.
If
you
pass
that
bookkeeper
around
with
the
record
or
tuple
right
you
might,
you
might
want
to
use
it
in
kind
of
a
global
way
where
you
have
just
one
bookkeeper,
but
then
things
will
just
be
held
alive
forever,
because
every
primitive
there's,
no
primitive.
That
has
identity
that
you
could
put
in
a
weak
map
or
that
has
like
unforgiability
as
this
core
property
right.
Exactly.
B
If
you're,
if
you're
using
this
in,
like
a
a
templating
scenario
where
you
control
both
sides
of
the
execution,
then
you
don't
need
the
informability.
So
you
can
just
use
array
indices
or
something.
But
if
you
want
that
extra
guarantee
and
want
to
not
have
to
deal
with
manual
memory
management,
then
you
need
something
more
and
our
proposed
solution
to
this
is
a
new,
primitive
type
called
box
that
and
the
additional
object
or
primitive
wrapper
capital
b
box
that
wraps
an
object
into
what
is
effectively
a
refi
func
object
pointer.
B
D
Oh,
wait,
wait,
wait,
it
doesn't
and
I
can
jump
to
the
explanation
of
that
or
we
could
like
hear
the
api
surface
and
then
I
can
explain
why
it
doesn't.
D
No,
that's
I
mean
so
when
you
so
you
you
have
this
box
constructor
that
takes
an
object
and
returns
a
primitive,
then
box.
Prototype
has
a
draft
method,
so
you
scroll
down
a
little
bit.
G
D
A
It's
if
you're
making
it
part
of
the
language,
a
principle
that
we
have
kept
to
is
that
the
primordials
have
no
hidden
state,
so
so
so
libraries
that
follow
best
practices
and
don't
mutate,
primordials
work
in
a
context
where
those
primordials
are
frozen.
A
We
are
not
going
to
be
introducing
stateful,
you
know
hidden
state
into
the
standard
primordial
heap.
D
A
You
know
so
let
me
let
me
let
me
cut
the
chase
on
something
one
of
the
things
I
was
expecting
to
say
when
you
got
there,
but
now
I
need
to
say
it
early
is.
I
previously
had
objected
to
unregistered
symbols
being
accepted
as
weak
map
keys,
and
I
read-
and
I
objected
to
it
for
good
reasons,
but
one,
but
it
was,
you
know
altogether
a
not
a
fatal
objection.
A
It
was
this
objection
with
a
certain
strength
and
at
the
time
there
was
no
compelling
use
case
for
unregistered
symbols
as
weak
map
keys.
I
think
you're
about
to
get
to
what
I
consider
to
be
a
compelling
use
case
and
given
that
compelling
use
case
that,
for
me
overcomes
my
reasons
to
object
from
for
to
unregistered
symbols
as
weak
map
keys.
D
Oh,
that's
really
interesting.
So
basically
I
see
these.
There
are
three
alternatives.
Basically
ref
collection
symbol
is
weak
map
keys
and
box.
The
diff.
The
main
difference
is
exactly
the
thing
that
mark
raised.
That
box.
Has
this
one
built-in
ref
collection?
That's
realm
wide,
it's
deniable,
but
it's
already
instantiated
for
you.
So
if
it's
unacceptable-
and
I
was,
I
was
wondering
how
unacceptable
that
would
be.
I
was
trying
to
convince
myself.
D
D
So
if
you
can
you
scroll
back
up
to
the
box
api,
the
thing
is
that
the
collection
name
was
totally
unintuitive
for
javascript
programmers
javascript
programmers
that
we
talked
to
about
this
so
far
like
to
think
about
boxing
objects.
But
what
you
actually
want
is
a
box
factory.
So
you
don't
want
there
to
be
a
single
box
per
box
factory
factory,
because
this
box
constructor,
is
a
box
factory.
A
No,
it's
the
the
the
when
you
have
multiple
compartments
with
inner
within
a
realm
with
frozen
primordials
you
you
want
them
to
be
able
to
use
the
full
normal
language,
which
therefore
includes
anything
that
that
you
know
is,
is
proposed
to
become
part
of
the
normal
language
and
still
not
have
a
communications
channel.
That
is
not
explicitly
granted
the
thing
about
your
box
factory.
That's
perfect
is
that
you
would
have
to
share
the
box
thing
that
the
box
factory,
I'm
sorry
when
you
say
box
factory.
D
Exactly
so
what
my
misunderstanding
was
I
thought
with
the
realm
api
we
might
be
moving
and
with
the
realm
shim
and
everything
going
in
that
direction,
we
might
have
been
moving
towards
a
world
where
every
time
you
have
a
membrane,
you
also
have
a
separate
realm,
and
in
that
case
I
thought
it
might
be
okay
to
have
box
be
there,
because
it
is
nicer
just
I'll
draft
on
it
directly.
But
if
that's
not
the
direction
then
good
to
know.
A
Yeah
tc,
53
and
xs
are
only
planning
a
single
realm
world
and
a
single
realm
world
where
the
ses
use,
which
is
the
one
that
tc
53,
is
adopting
as
the
base
standard
is
one
in
which
the
primordials
are
frozen
and
that's
the
means
of
isolating
subgraphs.
A
D
So
that's
good
context,
so
I'm
wondering
what
would
you
prefer
to
be
the
primitive
that
we
add
to
the
language?
Would
it
be
symbols
as
weak
map
keys,
allowing
you
to
build
your
own
ref
collection,
or
would
it
be
a
ready-made
ref
collection
or.
D
A
Okay,
so
that
so
it's
interesting
to
because
you're,
basically
your
box
factory
factory,
whatever
we
call,
it
is
essentially
your
ref
collection,
as
you
said,
except
that
it's
introducing
a
new
type.
D
Yeah,
but
the
new
type
is
a
very
superficial
thing.
I
mean
the
only
difference
between
box
and
symbol.
Is
that
you
know
besides
working
in
the
draft
method,
is
that
you
can't
use
it
as
a
property,
but
otherwise
it's
it's
totally.
You
know
the
the
poor.
The
core
thing
that
I
see
about
both
box
and
symbol
is
that
they're
unforgeable,
except
for
a
few
that
you
construct
through
certain
ways
and.
A
Well,
let's
be
very
specific,
we're
talking
about
unregistered
symbols
yeah,
so
I
so
I
still
think
I
favor,
but
the
box
thing
is
tempting,
but
it's
it's
fairly.
You
know
it's
still
fairly
heavy
to
introduce
a
new,
primitive
type
into
the
language.
A
Yes,
I
think
the
solution
that
I
favor
remains
that
we
allow
unregistered
symbols
specifically
unregistered
symbols
to
also
be
weak
map
keys.
H
D
A
H
Okay,
I'm
just
I'm
so
confused
about
the
the
box,
the
reference
in
the
context
of
multiple
realms
and
such
so.
You.
D
Get
it
well,
you
know
we,
we
presented
a
solution.
The
solution
doesn't
correspond
to
the
invariance.
This
group
is
working
towards,
and
so
I
don't
know
if
it
I
don't
know
if
it
makes
sense
to
spend
a
lot.
I
mean
I
could
clarify,
but
it
doesn't
meet
the
requirements.
E
I
know
we're
starting
to
run
short
of
time
here,
I'm
wondering
if
I
can
take
a
step
backwards
from
from
the
dot
from
the
details
here.
I've
been
I've
been
thinking
about
this
boxing
objects
spec
and
comparing
it
to
another
one.
I've
been
following
for
a
little
bit:
bradley's
compos
richard
keys,
spec.
E
Here's
what
I'm
getting
at
you've
got
a
you
you're,
trying
to
create
a.
What
effectively
is
you
is
a
you've
got
a
record
which
can
be
used
as
a
as
a
key,
which
is
a
composite
of
several
other
pieces
in
the
record
and
tuple
case,
those
are
based
off
of
primitives,
which
is
fine,
but
you,
but
now
you're,
trying
to
introduce
objects
into
that
model
with
non-primitives
which
are
not
which
are
harder
to
deal
with,
and
what
I'm
getting
at
is.
I
Here
so
there's
a
big
difference:
they're,
they
are
certainly
relatable,
but
they're
somewhat
inverted.
I
So
the
purpose
of
this
box
and
what's
being
talked
about,
is
to
essentially
relate
those
referential
types
versus
to
these
records
and
tuples,
whereas
kind
of
a
composite
key
was
taking
the
inverse
approach,
where
you
have
the
reference
type
and
you're
trying
to
convert
it
into
some
sort
of
opaque
value
type.
I
I
You
need
to
go
from
a
record
or
these
value
types
and
the
symbol
together
to
form
kind
of
a
position
and
then
from
there
use
where
you
get
the
value
back
out,
it
seems
to
me
at
least
to
be
inverted,
but
maybe
you
could
use
it
for
the
purpose
here.
E
Well,
I
was
really
looking
at
the
at
what
bach
the
box
of
an
object
would
be
a
component
in
the
overall
key.
As
I
understand,
which
here
is
a
record.
D
D
So
I'm
not
sure
it's
because
boxes
box
is
a
key
in
a
in
an
abstract
sense.
As
a
key
in
this,
this
draft
mapping
and
composite
keys,
you
know
the
the
reason
that
the
mapping
exists
is
because
it
has
to
be
weak.
Composite
keys
doesn't
have
to
do
with
that
kind
of
weak
mapping.
I
think
they're
just
unrelated,
except
in
maybe
some
high
level
sense.
I
Another
way
we
could
try
to
frame
that
is
composite
keys,
associate
data
with
a
group
of
objects,
and
what
box
is
doing
is
instead
having
data
that
is
associ
is
in
the
opposite
direction.
I
would
say
it
the
exact
same
way
in
english.
That's
that's
actually
quite
terrifying.
I
You
would
composite
key,
takes
reference,
referential
data
and
tries
to
bind
its
a
group
of
referential
data.
It's
trying
to
group
referential
data
there
we
go,
that's
a
good
way
of
putting
it,
and
this
is
instead
trying
to
take
a
value
and
then
allow
a
a
value,
not
not
reference
to
associate
with
a
group
of
references.
I
This
is
hard
to
explain.
I'm
I'm
very
sorry.
D
A
Because
we're
running
out
of
time
I
want
to-
and
I
and
I
think
we
are
where
we
are
on
the
relationship
between
those
two
proposals.
A
I
just
want
to
ask
if
you
have
thoughts
on
relationship
with
yet
another
proposal
that
you've
that
I
apologize
you've
tried
to
get
my
attention
on
and
I
haven't
been
giving
it
attention,
which
is
the
read-only
collections
proposal,
which
is
also
something
that's.
You
know
that
this
this
group
has
been.
You
know
helping
along.
D
Yeah,
I'm
really
excited
about
the
read-only
collections
proposal,
so
I
spent
a
while
thinking
about
this.
Actually
yehuda
katz
pressed
me
on
this
saying
like.
Should
we
really
like?
What
does
this
mean
conceptually?
Should
we
really
have
these
two
separate
things,
and
I
was
thinking
about?
Is
there
some
way
that
we
could
have
you
know?
If
these
collections
are
primitive,
then
they
can
only
point
to
primitives,
but
then
it
could
also
be
constructed
as
an
object.
D
I
I
came
to
the
mental
conclusion
that
we
really
do
want
two
separate
constructors
yeah,
but
that
they
should
be
analogous
right.
D
The
project
to
make
them
analogous
is
kind
of
slow
to
get
started
because
right
now
we
have
disjoint
sets
of
types
where
you
have
maps
and
typed
arrays,
presumably,
and
we
only
have
arrays
and
objects,
or
I
mean
the
the
primitive
equivalent.
I
think
eventually
it
would
make
sense
to
have
primitive
maps
and
things
like
that.
D
Like
record
maps,
I
don't
know
what
you'd
call
them
map
records
and
the
idea
at
that
point
would
be
to
make
sure
that
the
interfaces
are
analogous.
So
with
tuple
and
record
having
interfaces
that
are
analogous
to
object
and
array.
The
challenge
would
be,
for
you
know,
record
map
to
have
a
an
interface.
That's
totally
analogous
to
immutable
map.
B
D
D
D
D
And
so,
if
we
ever
had
an
immutable
array
which
I
understand
is
sort
of
under
debate
or
less
likely,
then
the
idea
would
be
that
we
would
use
the
same
apis
for
that.
So
I
would
really
want
to
coordinate
with
this
group
to
make
sure
that
we
that
we
have
apis
that
are
sort
of
cross
borrowable.
When
we
get
to
that
later
point
where
we
want
to
introduce
those
analogous
things.
A
Yeah-
and
I
would
certainly
consider
it
inbounds
and
in
fact,
attractive
to
expand
the
read-only
collections
proposal
to
include
something
array-like.
A
And
and
array-like
enough
that
having
it
be,
actually,
you
know
having
it
be
tuple-like,
but
but
within
the
the
overall
system
of
the
read-only
collections,
where
you
took
out
the
mutable
one
and
the
immutable
one
and
the
read-only
view
and
you've
got
the
the
methods
for
making
one
from
the
other.
So
I
I
think
I
see
these
things
as
exactly
as,
as
I
think
you
stated,
which
is
they
can
grow
to
be
analogous.
A
So
the
cognitive
burden
is
minimized,
of
learning
both
but
they're
still
disjoint
mechanisms.
C
On
a
naming
idea,
in
the
way
that
a
tuple
is
effectively
a
concise
way
to
say,
immutable
array
and
the
way
record
is
a
concise
way
of
saying
immutable
object.
If
you
find
yourself
needing
a
name
for
an
immutable
map,
an
idea
struck
me
to
call
it
a
relation.
C
D
Okay,
yeah,
I
think
I
kind
of
want
to
reduce
the
number
of
new
words
we
introduce
record
in
temple
is
already
two
words.
I
would
hope
that
if
we
make-
and
I
like
how
the
immutable
collections
proposal
just
introduces.
D
I
feel
a
little
bit
bet
like
we
had
other
drafts
that
were
like
constar
and
const
object,
but
then
that
was
also
like
this
is
misleading
because
they're,
not
arrays,
they're,
not
objects
and
one
one
thing
is:
there
would
be
no
sense
in
having
an
immutable
record,
an
immutable
object,
because
that's
just
object.freeze.