►
Description
We discussed with Daniel Ehrenberg the landscape for progress on records and tuples, reviewed the branches of the problem, and how each option introduces a new hazard for old code, but should not break any existing usage.
A
B
Yes,
I'm
very
happy
that
we're
spending
time
on
this
topic.
I
apologize
that
I
don't
have
a
more
coherent
presentation
prepared,
but
we
we
were.
We
had
some
interesting
discussion
recently
in
the
record
and
temple
monthly
meeting
about
about
this
as
well,
and
so
there's
a
question
about
about
this
deep
immutability
versus
what
mark
previously
described
as
shallow
immutability
or
what
I
would
describe
as
deep
immutability
with
a
with
an
escape
patch,
which
is
from
a
formal
perspective,
equivalent
from
a
from
an
expressivity
perspective
equivalent,
but
from
an
ergonomic
perspective.
B
It's
quite
different,
because
the
deep
immutability
by
default
encourages
more
correct
code.
Even
if
there's
in
some
sense
it
could
contain
references
to
objects.
So
from
from
our
investigation.
So
far
in
records
and
tuples,
it
seems
like
references
to
objects
from
within
a
mostly
immutable
data
structure,
especially,
for
example,
references
to
functions.
B
So
before
we
talk
about
how
it
connects
to
realms.
I
want
to
talk
briefly
about
do
people.
How
do
people
feel
about
this
concept
of
these
explicit
boxes?
For
these
mostly
deeply
mutable
data
structures,
together
with,
as
we
agreed
on
before
that,
there's
a
predicate
that
you
can
call
to
check.
Does
this
nested,
primitive,
record
or
tuple
contain
a
box
that
you
can
use
to
decide
whether
it's
necessary
to
continue
recursing
in
on
these
things?
So.
C
I
have
a
new
concern
that
that
that
goes
directly
to
this
issue,
and
it
came
from
my
doing
some
maintenance
work
on
some
of
our
own
code,
the
the
the
algorithm
of
harden,
and
then
I
realized
that
a
tremendous
amount
of
existing
code,
both
for
me
and
from
other
people
that
does
recursive
processing
of
structures
does
something
like.
Is
this
value
primitive?
C
C
One
is:
does
a
capital
object
of
foo
triple
equal
foo?
If
it's
primitive,
then
coercing
it
to
an
object,
creates
a
wrapper
which
is
not
triple
equal
to
itself,
and
I'm
sorry
is,
is
it
object?
Is
of
of
no
actually
the
the
the
the
triple
equal
is
fine
here,
because
if
it's
primitive,
then
it
won't
be
triple
equal.
C
All
of
it
needs
to
be
revised
before
it's
correct
again,
and
a
lot
of
that
code
is
library
code.
That's
trying
to
operate
at
a
meta
level
with
regard
to
other
code,
whereas
if
the
escape
hatch
is
symbols
as
weak
map
keys,
which
is
where
we
originally
started,
then
all
of
that
old
code
still
works
correctly
and
you
have
your
escape
hatch.
C
B
So
I
I
think
this
is
a
relatively
superficial
issue.
I
think
this
would
be
addressed,
for
example,
by
making
the
type
of
the
object.
It's
not
I
when
I
say
superficial
I
mean
it's
not
a
deep
issue
like
whether
things
are
shallowly
or
deeply
immutable.
This
is
an
issue
about
a
particular
compatibility
with
a
particular
coding
pattern
that
we
might
want
to
preserve,
and
I
think
that
there's
a
very
lo
there
are
a
number
of
local
fixes
like
using
identity-less
objects
that
just
comprehensively
solves
this
issue.
B
B
C
So
the
the
issue
of
old
code
being
this
is
that
I
mean
this
is
something
that,
until
I
was
until
I
had
the
aha
this
last
week
doing
maintenance
my
own
old
code.
I
didn't
really
appreciate
this,
but
but
in
general,
in
tc39
the
issue
of
of
not
breaking
old
deployed
library
code
that
that's
a
constraint
on
on.
You
know
what
we,
what
changes
the
language
we
can
make.
Has
you
know
that
has
been
a
forceful
constraint?
I
mean
I
have.
B
C
B
C
B
So
so
records
and
tuples
there's
a
limit
to
how
much
we
can
accommodate
old
code
old
code
can
assume
that
there's
a
fixed
set
of
typos
and
assume
fairly
directly
that
records
and
doubles
don't
exist,
and
that
will
be
a
false
assumption.
So
I
think
we
should.
I
think
we
should
orient
our
discussion
more
towards
towards
things
that
we
really
expect
to
come
up
and
that
we
value
we're
making
value
judgments.
When
we
talk
about
compatibility.
D
D
Yes,
and
it
requires
you
to
pass
a
new
code
path
in
general
to
these
libraries,
and
so
whenever
you
provide
stuff
in
javascript,
essentially
invalid
arguments,
it
can
blow
up
most
libraries
do
not
write
code
robust
enough
to
survive.
You
passing
very
exotic
things
in
in
this
case.
I
consider
adding
new
type
of
the
same
kind
of
exotic,
and
likewise
I
consider
identity
less
objects,
the
same
kind
of
exotic.
We
would
still
need
some
kind
of
check.
C
We
have
not
grown
the
type
of
strings
for
objects,
so
what
daniel
suggested,
which
is
that
its
type
of
object,
if
it's,
if
we
want
old
code
to
consider
them
to
be
objects,
is
fine.
If
we
for
something,
that's
that
should
be
considered
an
object.
I
would,
I
think,
that,
to
have
the
type
of
string
be
anything
other
than
object
or
function
would
break
too
much
old
code
to
have
if
records
and
tuples
are
primitives
to
have
the
typos
be
new,
primitive
strings.
C
B
C
C
Rather
when
you
dereference
a
primitive,
when
you
say
primitive
dot,
then
the
the
realm
of
the
code
with
the
dot
in
it
determines
what
prototype
the
property
is
looked
up
in
now.
If
records
and
tuples
are
identity-less
objects,
does
the
record
itself
inherit
from
something
or
the
you
know
the
tuple
itself?
Does
it
inherit
from
something.
B
C
C
B
Well,
because
this
all
gets
so
complicated,
I
kind
of
would
prefer
for
them
to
be
new,
primitive
types,
but
then
it
causes
this
other
problem.
I
I
still
really
do
think
that
this
is
quite
a
superficial
problem.
There's
there's
not
many
moving
parts
to
it.
It's
really
about
this.
One
surface
check
the
these
couple
different
surface
checks
that
you
that
you
have
with
type
of
or
wrappers.
C
A
B
B
That's
the
concern
that
mark
is
raising,
but
other
people
have
raised
other
reasons
why
they
prefer
identity,
less
objects.
For
example,
mozilla
has
repeatedly
said
they
prefer
identity,
less
objects,
because
primitives
are
complicated.
However,
when
we
went
over
the
equality
semantics
recently,
they
realized
that
their
implementation
strategy
with
no
different
operator,
behavior
or
anything,
was
just
not
going
to
work,
and
so
I
think
they're
reconsidering
that,
but
there
have
been
several
different
reasons.
You
know
peter
has
argued
that
it
would
be
complicated
to
break
programmer's
mental
model
with
new
kinds
of
primitives.
B
I
think
the
identity-less
objects
version
did
not
satisfy
his
concerns.
I
don't
fully
understand
why
yet-
but
I
guess
he's
not
here
today,
so
we
can
follow
up
about
that
another
day
and
so
yeah.
There
are
several
reasons
why
we
looked
into
this
design.
The
this
one
that
mark
is
raising
is
just
another
another
new
reason
why
we
might
consider
it.
A
D
So
I
I
think
we
could
frame
this
perhaps
in
a
different
way
that
would
better
address
the
workflow
that
we're
trying
to
talk
about
or
design
pattern.
It's
really
comes
down
to.
Do
we
want
people
to
in
general
traverse
these
things?
I
think
the
answer
is
yes
for
records
and
tuples.
Do
we
want
them
to
traverse?
Is
the
discussion
of
mark's
older
code
that
may
not
handle
things?
D
I
think
if
you
can't
traverse
things
to
get
to
mutable
state
via
something
like
box,
it's
a
usability
issue
and
these
two
are
just
in
detention.
So
it
comes
down
to
traversal.
I
think
just
by
nature
of
them
being
nested
has
to
be
one
of
the
goals
and
usability
wise,
not
having
box
makes
people
start
having
side
tables
and
I've
done
that
a
lot
personally,
it's
not
fun,
but
it
does
have
some
use
cases
that
can't
be
done
with
box.
A
Well,
I
so
I
I
personally
don't
think
that
traversal
should
be
coupled
to
the
cons
to
either
of
these
concepts
to
object
versus
primitive
or
to
the
output
of
type
of.
If,
if
we
were,
for
instance,
to
introduce
a
complex
type
to
ecmascript,
that
is,
you
know
a
a
number
with
an
imaginary
part
and
a
real
part.
I
think
that
would
be
a
primitive
and
I
think
that
you
would
be
able
to
access
the
parts
independently.
C
So
my
concern
about
the
traversal
is
that
there's
a
lot
of
old
code
where,
if
it
sees
type
of
that
these
things
are
type
of
objects,
object,
it
will
traverse
into
them,
which
is
fine,
and
if
it
sees
it's,
if
it,
if
it
sees
from
the
type
of
that
it
seems
to
be
a
primitive
that
it's
not
an
object
or
a
function,
then
it
won't
traverse
them
and
not.
Traversing
them
is
is
fine
in
the
case
where
they're
com
composite,
which
includes
complex
as
long
as
they're
transitively,
primitive.
C
C
A
B
B
One
model
is
basically
to
say
that
the
box,
basically
there
are
two
possible
models:
either
the
box
just
just
references,
the
object
directly
or
the
box
references
an
object
and
it's
only
accessible
within
a
particular
realm.
So
the
second
one
is
more
constrained,
and
there
are
some
reasons
why
I
was
imagining
that
we
might
go
along
these
lines.
B
C
B
B
D
I
think
that's
where
we
got
into
a
difference
in
record
and
tuple
just
by
nature
of
these
wrapped
functions.
I
have
concerns
about
treating
a
box
as
a
primitive
of
component
identity,
because
when
you
pass
a
function
across
at
least
the
realm
barrier
right
now
you
get
a
wrapped
form,
and
so,
when
you
round
trip
you
get
a
new
function
back.
B
B
So
I
see
two
solutions,
but
I
was
I
wanted
to
lay
out
the
options
before
we
get
into
the
thing
that
that
bradley
explained,
because
I'm
not
sure
how
how
intelligible
that
was
so
just
to
so
I
was
I
was
imagining
that
we
could
sort
of
go
all
out
here
and
say:
yeah,
you
know
a
box
can
be
this
kind
of
foreign
pointer
that
you
could
pass
into
another
realm.
Even
if
that
realm
is,
you
know
in
a
different
agent
or
across
this
callable
boundary,
and
then
you
could
pass
it
back.
B
B
Then
there's
also
the
case
of
where
it
is
the
same
agent,
and
in
that
case
I
think
that
the
conclusion
that
I
came
to
ultimately
was
well,
then
sure
it's
a
box
and
you
can
go
and
unbox
it.
In
the
same,
you
know
in
the
in
the
crossover
in
the
same
origin.
Iframe
case,
the
other
alternative
would
be
that
we
handle
these
in
kind
of
a
more
uniform
way
where
we
say
that
in
both
cases
the
the
box
cannot
be
unboxed
unless
you're
coming
from
the
same
realm.
So
you
could
imagine
it
like.
B
B
In
the
same
in
the
same
versus
different
case,
we
could
even
go
kind
of
all
out
and
say
well
if
we
are,
if
we're
in
another
realm,
but
the
thing
inside
is
callable,
then
we'll
put
like
a
callable
boundary
around
it,
but
anyway
it
would
have
this
difference
with
the
with
the
function
identity.
Another.
C
Thing
yeah:
I
want
to
raise
a
caution
here
against
dynamic,
scoping,
caller
or
or
put
it
more
generally
color
sensitivity
and
it
it's
in
general,
an
invoked
object,
as
we
were
talking
about
with
proxies
an
invoked
object,
cannot
cannot
have
a
behavior,
that's
sensitive
to
who
it's
and
who
is
invoking.
It.
B
E
E
Is
the
box
itself,
the
the
the
box?
Built-In
methods
will
be
on
the
realm,
and
they
they
have
a
certain
capabilities,
is
kind
of
trying
to
operate
on
a
day-date
date.
Object
proxy
around
a
data
object
that
you're
trying
to
use
through
the
building
method,
or
something
like
that.
Something
equivalent
to
that.
It
feels
to
me
that
it's
fine.
C
B
E
B
I
want
to
wrap
up
the
kind
of
conclusions
on
this
topic
because
we're
coming
to
the
end
of
the
the
meeting,
so
it
sounds
like
there's
this
kind
of
broad
understanding
of
the
the
high
level
need
for
for
box
of
having
this
deeply
immutable
with
an
escape
hatch.
We
do
have
this
problem
to
solve,
of
how
it
should
how
we
should
maintain
compatibility
with
with
membrane
systems
that
assume
that
primitives
don't
have
anything.
That's
that's.
B
B
C
B
C
C
B
C
C
I
you
know
I
favor,
but
I'm
glad
to
you
know
to
to
to
you
know,
be
gaining
clarity
about
this.
The
other
thing
I
want
to
raise
here
is
that
if
records
and
tuples
are
identity,
free
objects,
rather
than
primitives
than
the
case
four
box,
which
has
always
seemed
weak
to
me,
the
case
for
box
seems
weaker.
B
I
continue
to
disagree.
I
tried
to
explain
the
motivation
for
box.
The
motivation
for
box
does
not
relate
to
whether
we
call
this
a
primitive
or
an
identity-less
object,
it's
about
being
deeply
immutable
by
default
and
shallowly
and
and
having
an
escape
hatch,
which
would
lead,
lend
itself
to
completely
different
usage
patterns
from
something
which
is
not
deeply
mutable
by
default.