►
From YouTube: SES Meeting: Records and Tuples as they relate to Realms
Description
Robin Ricard leads a discussion about Records and Tuples and a potential interaction with Realms. Debate continues to weigh two possible directions for the proposal to make progress past security and complexity obstacles.
A
All
right
welcome
to
the
june
30th
cess
meeting.
We
have
a
planned
conversation
about
records
and
tuples
and
and
all
parties
who
are
interested
in
that
are
here.
I
will
leave
it
to
mark
mark.
Would
you
like
to
make
an
announcement
about
cess.
B
Yeah,
so
there's
actually
two
things
going
on
the
big
one
is
the
cestival
that's
coming
up
the
that
is
a
group
of
people
that
are
going
to
be
gathered
for
a
full
week
in
dean's
house,
which
is
also
the
what
what
was
before
covid
the
agora
headquarters
as
well.
In
many
cases,
we'll
all
be
now
that
we're
all
vaccinated
we'll
be
gathering
for
a
full
week.
B
This
is
several
folk
from
metamask,
as
well
as
zegoric,
in
order
to
attack
the
core
of
the
shin
to
try
to
find
flaws
to
try
to
attack
it
to
try
to
just
do
it.
Do
a
hardcore
attack
review
as
we
call
and
that's
every
attack
review.
I've
lived
through
before
has
been
a
hellacious
and
incredibly
productive
experience,
and
it's
going
to
be
an
immersive
week,
which
is
the
right
way
to
do
that
where
we
just
all
do
this
in
the
same
place
at
the
same
time
in
a
full-time
manner.
B
The
other
thing
that's
going
on
is
that
leased
authority
is
a
security
auditing,
firm,
very
active
in
the
blockchain
space
and
they'll
also
they
are
regarding
a
audit
of
cess
and
examination.
Critical
examination
of
the
session
and
least
authority,
as
one
would
guess
from
their
name,
is
an
organization
that
already
knows
about
issues
of
capabilities
and
capability
security
model.
Lease
authority,
and
some
of
the
people
who
are
prominent
in
that
area
will
be
part
of
this
audit
effort.
So
so
we've
got
some
good
critical
examination
going
on.
A
Awesome.
The
other
point
is
something
that
thank
you
alex
for
keeping
these
up
to
date.
I
believe
that
you
are
the
one
who
leaves
these
notes
in
our
agenda
that
this
is
the
last
sess
meeting
before
the
submission
deadline
for
topics
for
the
next
plenary.
I
think
that
we
are
pretty.
We
know
what
we're
going
to
talk
about
next
time
at
plenary
leo
are
we
are
we
going
to
see
realms,
come
up
for
another
round
of
conversation.
C
Probably
next
week
I'm
trying
I'm
just
back
from
a
more
than
a
week-long
vacation,
I'm
reaching
out
to
jordan,
but
I
still
need
to
get
him
to
to
answer
like
I've
had
a
follow-up
after
that
meeting,
just
a
quick
heads
up.
I
had
to
follow
up
after
that.
Maybe
I
talked
to
jordan,
trying
to
get
to
the
next
steps.
C
Jordan
wanted
wanted
to
understand
more
and
he
he
said
he
would
love
like
to
see
like
some
polyfill
implementation,
with
an
actual
main
brains
framework
on
top
of
that,
and
we
actually
had
those
I
just
had
to
send
the
links
separately.
C
I'm
not
sure
if
that's
like
good
enough
for
what
he
wanted
to
to
see,
but
it's
still
like.
I
still
tried
to
get
him
to
to
tell
me
what
he
he
thought
about
that
that
that
happened
before
vacation
time
and
now
I
think
he
got
he
got
more
than
10
days
to
to
look
at
it.
If
not,
I
hope
he
does
it
this
week
and
then
we
can
get
like
some
other
update
in
the
next
week.
C
He
wanted
to
see
a
main
brains
framework
working
with
that
realm
and
they
show
like
hey
here.
We
have,
we
have
a
membrane.
There
is
basically
the
same
membrane
structure
that
caridi
did
with
the
near
membrane,
but
it's
just
adapted
for
for
this
one.
It's
not
the
full,
complete
main
brain
system
like
all
the
things
that
we
have
for,
and
we
are
using
for
salesforce
right
now,
and
also
that
the
the
polyfill
is
pretty
complete
in
terms
of
where
we
use
evaluate.
C
But
of
course,
I'm
not
getting
that
frame
the
the
polyfill
with
the
import
due
to
like
so
many
entanglements
that
we
would
need
to
to
to
have
to
implement
the
import
value
part
in
a
polyfill
like
in
a
real
world.
What
would
be
amazing,
but
we
have
those
parts
and
we
wanted
and
the
the
parts
are
working
and
they're
working
together.
C
I
have
the
polyfill
working
the
main
brain
framework
working
on
the
top
of
polyfill,
and
I
have
another
example
of
the
this
main
brain
framework
using
an
iframe
directly
and
the
results
are
the
same.
I
just
switch
from
one
thing
to
another.
The
results
are
the
same.
This
is
like
this
is
the
part
that
I
like
that
gets
me
satisfied
with
this
membrane
framework
implementation
with
the
polyfill
and
everything,
because
I'm
still
getting
the
same
results
and
being
able
to
verify
those.
I
have
plenty
of
tasks
for
the
polyfill.
C
I
have
more
sort
of
like
manual
tests
for
this
main
brains
framework,
but
that
I
just
need
to
run
directly
to
to
verify
results,
but
they
seem
okay
and
I
hope
jordan
sees
that
sees
it
the
same
way.
Let's
see
how
it
goes
for
the
next
week.
A
Awesome
well
with
that,
let's,
let's
dive
into
the
the
oft
postponed
topic
of
the
day,
robin
I
believe,
you're
leading.
D
D
So
today
we
would
like
to
propose
the
following
and
then
get
some
feedback
on
it
and
see
if
that
that's
going
to
be
a
design,
that's
going
to
play
nice
with
realms.
D
So
what
we're
proposing
today
is
to
change
the
behavior
of
boxes
if
they
want
to
pass
through
boundaries,
so
we
would
essentially
say
that
you
should
throw
if
you
try
to
pass
a
box
across
a
real
boundary
to
another
realm.
The
reason
for
that
is
that,
from
our
point
of
view
in
record
and
tuple,
we
are
more
interested
in
the
developer
experience
aspect
of
the
box
rather
than
having
that
as
a
tool
to
transmit
to
another
realm.
D
If
you
want
to
transmit
that
kind
of
data,
so
that
means
objects
inside
of
a
recurrent
tuple
structure.
You
might
as
well
use
a
membrane
to
do
that
and
you
don't
need
a
box.
So
essentially
the
proposal
is:
if
the
realm
api
see
a
box,
they
they
can't
throw
and
how
we
intend
to
give
you
that
possibility
of
checking
is
through
an
abstract
operation
that
we
have
written
in
the
spec.
D
That's
called
weak
receive
contains
box,
so
that's
part
of
the
record
integral
spec,
so
yeah
you
can-
or
we
can
add,
that
check
to
to
realms
in
order
to
make
sure
that
this
that
any
structure
doesn't
contain
any
boxes,
etc.
F
It
could
be,
I
mean,
maybe
maybe
I
can
explain.
I
think
this
this
we
kind
of
jumped
into
a
lot
of
details
so
that
the
model
is
we
have
records
and
tuples,
which
are
which
are
primitives,
but
they
can
contain
boxes
which,
which
can
can
have
objects.
F
So
there's
a
fundamental
operation
box
dot
contains
box,
something
like
that
would
be
something
different.
That
says
whether
something
contains
a
box,
so
we
were
previously
thinking
that
maybe
a
box
could
be
something
that
you
opaquely
passed
to
a
realm
and
then
passed
back,
and
I
think
bradley
correctly
pointed
out
that
this
is
this
gets
very
complicated
and
so
we're
instead
thinking
that
we
treat
boxes
or
records
and
tuples
containing
boxes
just
the
same
way
as
we
treat
objects.
So
if
you're
passing
it,
somebody
has
static.
F
In
the
background
everybody
knew
oh
yeah
thanks,
so
we
would
treat
it
just
the
same
ways
with
objects
in
realms
and
in
same
origin,
iframes.
So
in
the
same
origin,
iframe
case,
if
you
have
a
record
or
tuple
with
a
box
in
it
sure
it's
fine,
you
can
just
pass
it
to
another
same
origin
iframe.
But
if
you
pass
it
to
a
realm,
it
would
be
an
error
just
like
if
you're
passing
an
object
to
a
realm,
because
that
you
should
instead
be
handling
it
with
a
membrane.
F
I'm
just
saying
what
what
robin
said,
but
in
different
words.
So
hopefully
this
should
address
one
concern.
There
was
another
concern
that
mark
had
raised,
which
is
shouldn't.
We
like
not
do
records
and
tuples
and
instead
do
some
deep
freeze
thing,
and
I
wanted
to
talk
about
that
too.
But
we
could
first
talk
about
the
realm
issue
and
and
the
the
box
issue,
and
then
we
could
talk
about
that
other
one.
B
The
overall
shape
of
the
concern
there
is
a
lot
of
existing
code.
That
has
logic,
has
a
has
basically
case
switch
logic
of
the
form,
whether
whether
obviously,
whether
it's
a
conditional
or
a
case,
but
is
this
a
primitive?
B
Otherwise
do
some
kind
of
recursive,
wrapping
or
unwrapping
or
whatever
it
is,
and
that's
in
particular,
very
common
with
membranes
is,
is
just
that
that
if
it's
a
primitive,
it's
just
a
pass-through
with
no
further
intervention,
and
if
records
and
tuples
are
considered
primitives
and
they're
transitively
primitive,
then
the
rationale
for
that
case
switch
continues
to
apply
that
case
that
that
letting,
if
it's
transitively,
immutable,
transitively,
primitive,
then
letting
it
through
in
that
branch
of
the
logic
of
those
of
of
those
libraries
is
still
valid.
It's
still
safe,
syria
used.
F
Can
I
can
I
stop
you?
You
explained
this
before.
I
think
this
is
an
important
issue,
but
I
think
it's
separate
you're
talking
about
whether
box
is
viable
at
all.
So
maybe
we
could
do
this
topic.
Please
mute.
Whoever
keeps
having
static
way.
We
can
cue
this
topic
and
then
we're
gonna
start
to
talk
about.
If
we
have
box,
then
how
would
it
work
with
realms?
Then
we
could
talk
about.
Can
we
have
box
and
then
we
can
talk
about?
We
can
also
talk
about
this
broader
issue
that
you
also
raised.
B
So
so
let
me
just
mention
one
more
thing:
on
the
deep
freeze
slide,
which
is
immune,
conventional
immutable
objects.
You
know
deeply
frozen,
plain
objects.
B
B
Is
that
means
that
now
there
are
objects
that
are
considered
to
be
objects,
not
primitives,
that
cannot
be
keys
in
weak
maps
and
that
you
cannot
have
weak
references
to
so
it
just
kind
of
explodes
the
state
space
of
combinations
of
objects
versus
non-objects
versus
keys
versus,
not
keys.
So
so
that's
it.
I've
raised
the
issues
I
wanted
to
raise.
F
F
Okay,
so
for
the
second
one
about
records
and
doubles
and
weaknesses,
I
think
when
a
record
or
tuple
contains
a
box
that
has
an
object
in
it.
Then
it
would
be
okay
to
have
the
weakness
key,
but
that's
kind
of
more
complicated
and
exotic
overall
about
these
categorizations
you're
you're
right.
These
would
be
different
kinds
of
objects.
They
would
they.
F
F
I
think
we've
shown
that
it's
worth
it
I
mean
also
bradley
has
shown
that
it's
worth
it
to
have
these
things
that
are
compared
by
value
at
some
level
and
contain
objects,
and
you
know-
and
there
are
different
ways
that
we
could
set
up
the
defaults
we
talked
about
previously,
they
could
be
added
to
those
objects
or
they
could
be
primitives
like
that's
one
or
the
other.
We
have
a
clear
decision
space
and
I
think
it's
overall
worth
it
to
do,
even
though
these
costs
that
you
enumerated,
you
know
exist.
E
E
E
E
If
you
do
that,
you're
going
to
break
one
half
of
those
switch
cases
in
either
direction,
I'm
not
sure
that
we're
actually
safer
by
stating
only
the
switch
cases
that
check
for
boolean
string
etc
are
safe.
I
don't
think
that's
actually
true
right
now,
because
we've
introduced
more
primitives
over
time.
We've
never
introduced
more
identity
over
time
for
type
of,
and
so
I
generally
code
with
the
pattern
of
checking
for
identity
types,
because
I
don't
know
if
primitive
types
are
going
to
expand
over
time.
E
B
B
Using
an
if
capital
object
of
x
triple
equal
x
as
a
primitive
test,
which
basically
says
if
it's
a
primitive,
then
capital
object
of
it
creates
a
wrapper
which
is
not
the
same
as
the
thing
itself.
B
So
if
capital
object
of
it
is
the
same
as
the
thing
it
is
itself,
then
it's
an
object,
not
a
primitive.
So
that's
that's
one
pattern.
I've
seen
and
chris
kowal
will
be
quick
to
point
out
that
croc
for
or
or
chip,
maybe
that
crockford
is
really
quite
horrified
about
that
pattern,
but
nevertheless
I've
used
it
and
I've
seen
other
people
use
it.
B
It
won't
get
misled
into
doing
something:
that's
on
that's
silently
unsafe
and
then
the
remaining
one
is
the
one
that
bradley
brought
up,
which
is
assuming
that
the
object
types
are
exactly
type
of
x,
triple
equal
object
and
and
x
is
not
null
and
a
type
of
type
of
x
triple
equals
function.
B
So
if
it's
any
string
other
than
function
or
object,
it's
assumed
to
be
primitive
and
and
I've
both
written
that
and
I've
seen
that.
So
so,
given
that
and
given
the
security
assumptions
behind
making
those
tests,
what
I
would
say
is
that
the
is
that
of
the
possibilities
we're
talking
about
the
ones
that
are
not
safety
breaking
would
be
that
records
and
tuples
are
introduced
with
new
type
ofs
and
are
transitively
primitive.
That
would
not
break
any
assumptions
of
such
code
or
that
we
support.
B
We
have
provide
good
language,
support
for
transitively
immutable
object,
structures
with
identity
and
then
those
are
simply
type
of
object,
because
they're
they're
simply
objects
within
the
existing
object
model,
but
we
we
provide
better
language
support
like
purify,
primitives
or
hardened
primitives
or
whatever,
or
maybe
syntax
provide
better
language
primitives
for
knowing
that
you've
created
transit
of
the
immutable
object
structures.
F
B
Okay,
it
won't
solve
the
equality
problem,
so
if
the
equality
problem
is
the
driving
problem,
let's,
let's
let
me
talk
about
that
some,
so
I
mean.
F
F
I
mean
the
whole
like
double
key
proposal
like
it's
a
whole
separate
proposal
that
would
be
kind
of
subsumed
by
records
and
tuples
boxes.
E
So
so
I
can
just
clarify
yeah,
so
he's
talking
about
richard
keys
and
a
significant
portion
of
the
use
cases
for
richer
keys
would
be
doable
with
records
and
tuples,
not
all
of
them,
but
a
significant
amount
in
particular.
The
use
case
I
am
interested
in
for
records
and
tuples
is
not
affected
by
having
box
inside
them,
but
I
have
seen
comments
on
my
other
proposal
that
people
want
to
get
those
kind
of
keys
of
multiple
component
parts
done
easier
and
that
would
be
solved
with
box.
B
So
let
me
make
sure
I
understand
the
idea
is
that
so,
first
of
all,
you're
trying
to
allow
these
both
as
weak
map
keys
as
well
as
map
keys,
is
that
correct.
E
For
richer
keys,
the
intent
was
to
allow
weak
map
keys
for
records
and
tuples.
I
don't
know
the
actual
champion
stance.
You
would
have
they're
here
well.
F
B
They,
it
would
also
work
if
they
contain
symbols.
Correct.
F
F
Not
I
mean,
I
think
I
think
we
would
need
something
more
concrete.
I
think
that
was
that
you
know
the
the
presentation
I
think
was
too
abstract
for
the
community.
B
B
I'm
still
hopeful
about
symbols
as
weak
map
keys,
the
in
any
case,
whatever
the
the
current
status
of
advancement
in
the
committee.
Technically
symbols
of
weak
map
keys
mean
that
records
and
tuples
containing
symbols
could
also
be
weak,
mapped
keys
with
the
advantages
that
you're
talking
about.
B
F
So
you
know,
I
think
we
we've
made
a
case
for
why
box
is
valuable
and
yeah.
I
was
definitely
kind
of
talking
too
quickly
through
the
weak
map
case
and
that
definitely
deserves
more
more
thought.
F
But
the
you
know,
I
think
we
you
know,
the
the
the
kind
of
structural
comparison
is
core
goal
of
the
proposal
and
being
able
to
have
references
to
objects
is
a
core
thing
that
we've
found
is
a
requirement
from
from
users
as
well
as
the
you
know,
people
talking
about
symbols
being
symbols
as
weak
map,
keys
being
too
awkward
a
way
to
accomplish
the
same
thing:
that's
the
feedback,
we've
gotten.
So
this
is
why
we've
been
proposing
box
as
this
replacement,
so
or
is
it
as
like
an
upgrade
that
lives
alongside
symbolism?
F
F
Understand
a
little
bit
more
about
what
I
can
see
how
it
does
complicate
this
code
a
little
bit,
but
I'm
really
you
know
I'm.
I
don't
really
understand
the
compatibility
issues,
because
when
you
have
a
code
base
that
has
membranes
I
mean
can't
you
upgrade
to
the
newer
version
of
membranes.
That
knows
about
records
and
doubles.
I
don't
understand
why
that's
this
gigantic
blocker,
the.
B
The
problem
is
that
there's
existing
membranes
out
there
in
the
world
that
become
unsafe,
especially
when
the
the
new
abilities
are
reachable
by
syntax.
F
B
Then
it
will
allow
the
record
and
tuple
over
to
the
other
side
of
the
membrane
without
wrapping
and
unwrapping
it
and
thereby
not
intermediate
the
box.
F
Okay,
so
right
so
one
thing
we
could
do
is
we
talked
about
the
identity
list
objects
and
the
thing
that
you
thought
was
bad
about.
Those
is
that
they
can't
be
weak
map
keys,
but
imagine
that
if
you
try
to
use
them
as
a
weak
map
key,
they
would
throw
an
exception.
So
what
would
the
problem
be?
B
So
that
the
the
weak
map
having
them
not
be
weak
map
keys,
is
not.
That
itself
is
not
a
security
problem
that
and
it's
that
is
just
a
complexity
of
the
language
problem,
and
that
now
we've
got
primitives
that
can't
be
weak
map
keys.
We
potentially
have
primitives
that
can
be
weak
map
keys.
We
have
objects
that
can
be
weak
map
keys
and
we
have
objects
that
cannot
be
weak
map
keys,
it's
just
it
makes
I
mean
in
some
sense.
B
F
Okay,
so
I
can
see
how
these
are
downsides,
but
I'm
not
quite
convinced
that
they're,
like
fatal
flaws.
I
would
be
a
lot
more
convinced
if
we
saw
real
well
like
we're,
saying
compositions
of
membrane
systems
that
that
really
show
that
it
that
it
caused
a
problem
to
use
record
in
temple
like
what.
If
we,
what
if
we
work
today
to
really
try
to
change
as
many
membrane
code
bases
as
possible
to
using
this
pattern
of
checking
only
the
types
that
it
knows
about
and
throwing
an
error
on
types
that
it
doesn't
know
about.
F
B
Yeah,
the
the
and
the
the
issue
is
obviously
not
so
much
for
the
membrane
for
the
particular
membrane
libraries
that
you
know
about,
because,
obviously,
for
those
we
can
just
do
it.
The
question
is:
can
we
identify
all
of
the
things
that
we
would
be
breaking
that
we
don't
know
about
that?
We
don't
currently
know
about.
You
know
it's
very
very
much.
The
way
we've
dealt
with
other
issues
about
tc39
can't
break
the
web.
B
F
So
maybe
maybe
if
we
examine
these
code
paths
we'll
find
a
place
that
either
naturally
or
we
could
make
some
change
in
the
semantics
that
will
make
the
error
be
greater.
If
we
look
at
how
these
things
these
things
work,
I'm
trying
to
think
of
an
example.
But
you
know,
for
example,
if
you
made
a
proxy
with
the
record
as
its
target,
and
I
think
we
would
make
that
not
work,
but
that's
not
something
that
you
do
because
you
use
a
shadow
target,
but
maybe
there's
something
analogous
to
that.
F
Some
operation
involved
in
setting
up
a
membrane
that
you
know
that
we
can
kind
of
make
sure
wouldn't
work.
B
F
F
I
guess
these
two
kind
of
suggestions
where
one
suggestion
is
one
suggestion
is
looking
into
how
you
know
whether
the
type
checks
that
you
know
about
couldn't
be
changed,
whether
that's
practical
and
the
other
suggestion
being
about.
F
F
Okay,
thanks
for
thanks
for
talking
about
this
yeah.
Thank
you
very
much.
F
I
think
for
now
we're
going
to
continue
developing
the
record
and
temple,
or
I
want
to
suggest
to
to
robin
the
champion
that
we
continue
developing
the
proposal
with
the
you
know,
as
it
is
right
now
for
for
now,
with
records
and
tuples
being
primitives
and
being
able
to
contain
boxes
because
we've
gotten.
This
is
the
direction
that
the
the
community
feedback
has
pushed
us
in,
hoping
that
we'll
be
able
to
resolve
this
membrane
issue
in
one
or
both
of
those
ways
that
we
just
articulated.
B
F
D
I
I
think,
personally,
that
it
is,
it
is
technically
definitely
doable.
We
can
definitely
separate
them
whether
we
want
exchange
to
do
it.
I
think
we
need
to
discuss
that,
because
there
is
a
possibility
that
if
we
separate
bugs,
we
kind
of
also
like,
if
we're
not
sure
we
have
a
way
to
solve
those
issues,
we're
essentially
killing
bugs.
D
So
this
is
something
that
we
are
that
we
need
to
discuss,
but
that's
it.
So
I
can't
guarantee
anything
just
right
now,.
B
B
D
D
E
E
E
We're
talking
about
right
now
are
making
assumptions
about
what
state
can
be
kept
within
a
object
graph
if
you're,
given
a
value,
if
we
don't
include
box,
you
can
already
attach
state
with
maps
to
things
as
a
lookup
table
of
sorts,
so
we
can
already
attach
some
state
to
records,
but
it's
not
identity
based
state
with
box
you're,
essentially
doing
that
in
a
way,
that's
reflective,
you
can
traverse
and
find
it
walk
and
find
it.
E
Instead
of
needing
to
have
this
side
table,
I
think
if
people
are
making
the
assumption
that
we
introduce
record
in
tuple
and
you
cannot
traverse
in
order
to
find
this
kind
of
mutable
state,
because
there
is
no
box,
we
just
start
making
it
harder
for
box
to
exist
because
you're,
encouraging
coding
patterns
roughly
that
state
that
these
are
safe.
When
we
know
we're
planning
on
effectively
trying
to
make
them
have
mutable
state,
potentially.
F
F
I'm
not
sure
because
we
would
want
people
to
check
the
king's
box
function,
but
that
function
won't
exist
yet
so
there's
no.
It's
not
a
great,
not
a
great
pattern
to
encourage
people
to
use,
but
I
do
want
to
kind
of
question
a
little
bit
the
premise
of
the
way
that
mark
framed.
This
mark
was
saying:
if
we
can't
solve
the
box
problem,
I
think
I
think
we
have
a
solution,
but
the
thing
is
that
it
has
trade-offs,
and
the
question
is
whether
we
want
to
to
take
those
trade-offs.
F
F
I
guess
everyone
here
works
on
pieces
of
software
that
are
maintained
and
I'm
not
I'm
not
sure.
I
don't
have
enough
background
how
many
red
systems
are
used
today,
but
I'm
not
sure
if
we're.
Yet
at
the
point
where
we
have
to
worry
about
old
membrane
systems
being
used
on
new
engines
where
the
margin
of
age
is
more
than
two
years,
I
would
I
would.
I
would
think
that
you
know
if
you're
using
it
in
a
web
browser
which
is
the
case
where
you
know
the
you
have
the
least
control
over
your
engine.
F
Well,
two
years
is
enough
time
to
update
your
website.
Maybe
you
know
you
should
update
your
dependencies
over
the
course
of
two
years
I
think,
and
if
you're
using,
if
you're
doing
an
embedded
system,
then
you
have
control
over
the
the
engine
that
it's
running
and
you'll
have
an
explicit
upgrade
step.
B
Okay,
so
as
as
an
example,
the
kaha
teaming
membrane
from
the
google
kaha
project,
which
is
the
the
predecessor
of
modern
cess,
it
was
a
ces
designed
around
ecmascript
5
era.
Javascript
and
the
taming
membrane
doesn't
use
a
proxy,
so
you
can't
so
to
search
for
it.
If
you
were
looking
for
proxy,
you
wouldn't
find
it
the
and
it
would
you
know
it's
no
longer
being
maintained,
they're,
certainly
not
the.
B
It
would
be
very
difficult
to
get
google's
attention
to
try
to
upgrade
it
to
spend
the
effort
to
try
to
upgrade
it.
But
it's
it's.
You
know
it's
out
there,
it's
being
used
not
just
by
google,
and
this
would
introduce
an
unsafety
in
it.
F
F
B
I
mostly
I'm
using
it
as
an
example,
but
yes,
the
the
particular
thing
should
be.
You
know
the
the
the
we
should
definitely
be
concerned
about
the
particular
yeah.
F
I'm
not
convinced
that
we
should
be
concerned
about
unbounded
examples
of
membrane
libraries
that
might
exist.
I'm
not
convinced
that
should
be
in
scope
for
us,
because
even
when
we're
talking
about
web
compatibility,
web
compatibility
is
not
limitless.
Sometimes
you
do
things
that
have
web
compatibility.
B
F
B
Certainly,
certainly
not
limitless,
we've.
Definitely
you
know
in
the
in
in
tc39.
Over
and
over
again,
we
have
taken
steps
that
have
been
technically
not
upwards
compatible
from
the
web.
We've
released
them
we've,
but
we
we
try
very
hard
to
be
careful
and
to
weigh
the
trade-offs,
and
so
I
certainly
completely
agree
this.
These
are
all
trade-offs,
but
we
tru.
F
Yeah,
so
for
that
unmaintained
old
stuff,
I
think
we
take
that
very
seriously
when
it's
very
widely
deployed.
So
the
question
is
about
whether
this
is
very
widely
deployed
and,
in
this
case
not
just
widely
deployed
with
existing
code.
No,
this
is
why
mood
tools
is
relevant.
This
is
why
we
made
compatibility
issues
for
changes
for
move
tools,
because
the
old
version
of
mood
tools
was
widely
deployed.
F
F
B
So
the
I
think
we
might
are
you
know
our
subjective
sense
of
the
waiting
might
be
different,
but
the
question
is
completely
valid.
I
mean
we
all
agree
that
it's
a
trade-off
and
that
tc39
has
proceeded
to
do
things
that
have
that
have
caused
minor
breakage
and
have
certainly
been
deterred
by
things
that
have
gone
over
some
some
threshold.
B
So
so
all
of
this
is
all
of
these.
Questions
are
completely
valid.
F
Sorry,
I'm
not
sure
if
you
heard
me
for
for
next
steps
here
I
was
suggesting
some
some
investigations
that
the
membrane
community
could
do.
F
F
F
B
Part
of
the
issue
that
I'm
raising
is
that
it's
not
clear
how
to
collect
this
information
in
an
adequate
way,
because
there's
no
obvious
symptom
of
whether
whether
code
is
doing
membrane-like
things,
for
example,
it
can
be
doing
membrane-like
things
without
using
the
proxy
constructor
so
or
you
know,
to
put
it
another
way,
something
that's
where
it's
doing
this
kind
of
case
division,
where
it's
making
an
unsafe
assumption
is
making
an
assumption
that
would
be
unsafe
on
one
side
of
that
case.
B
F
So
whenever
a
change
is
made
to
javascript
there's,
you
know
an
infinite
number
of
statements
about
javascript
that
become
false.
That
were
previously
true.
So
I
think
we
I
think
to
to
assert
that
this
is
a
blocker
for
the
proposal.
We
should
have
some
evidence
that
this
that
this
occurs.
I
don't
think
this
is
much.
F
E
B
And,
and
certainly
if
we
search
for
you
know
type
of
where,
where
function
and
object
is
treated
one
way
and
all
others
are
treated
another
way.
Well,
I'm
sure
we'll
get
millions
of
hits.
A
B
F
So
that's
good,
I
mean
the
other
thing
is
I
didn't
hear
like
an
extremely
killer
argument
against
the
identity
mark
argued
that
it
would
be
more
complex,
which
I
you
know,
which
I
did
it
that's
a
trade-off
that
doesn't
sound
to
me
like
there's,
absolutely
no
solution
for
box.
That
sounds
like
a
solution.
That's
kind
of
sub-optimal
in
some
way.
I'm.
B
Sorry,
I
think
I
missed
the
critical
syllable
that
what
would
be
more
complex.
F
Oh,
the
the
identity
objects
solution,
yes
yeah,
you,
you
articulated,
and
I
agree
with
you-
that
it
adds
complexity.
What
I
didn't
understand
was
why
this
is
fatally
bad.
It.
B
Is
so
I'm
not
I'm,
I
did
not
say
it
was
fatally
bad,
so
so
that
is
something
that
that
I
would
consider
to
be.
You
know
once
I
mean.
Obviously
these
are
all
trade-offs.
Complexity
is
certainly
a
cost,
but
the
making
these
identities
objects.
I
don't
see
that
that
increases
in
unsafety
so
and
it's
the
silent
unsafety,
which
is
the
thing
that
really
terrifies
me
so
so
this
would
not
be
on
the
the
bad
side
of
the
silent
safety
issue.
F
So
I
would
be
fine
with
as
a
resolution
to
this
meeting.
I
don't
know
if
robin
would
disagree
to
say
like
okay
well,
because
it
resolves
the
silent
on
safety
issues
that
we
know
about
we're,
gonna
postulate
that
we'll
go
with
identity-less
objects
together
with
like
a
record
dot,
isrecord
and
tuple.istuple
thing,
and
those
will
fully
look
like
objects
to
both
tests.
F
The
type
of
test
and
the
wrapper
test,
but
they'll
still
have
structural
equality
and
they'll
have
box
and
they'll
have
a
box
that
contains
box,
and
it
does
have
this
extra
source
of
complexity.
Where
now
you
know,
if
it
doesn't
contain
a
box,
then
it
cannot
go
in
a
weak
map
and
that's
a
or
if
it
doesn't
contain
a
box
that
has
an
object
in
it.
F
F
Yeah,
so
you
know,
if
you
want
to
make,
if
you
want
to
proxy
a
record
or
tuple,
I
mean
you
want
to
do
a
membrane
around
a
record
or
tuple
just
make
a
record
or
trouble
on
the
other
side.
Oh
yeah,
the
other
thing
about
them
is
as
identities
objects.
They
do
have
this
very
bizarre
thing
where,
when
you
get
the
prototype
you're
getting
the
prototype
of
the
current
realm,
so
they
are
like
realm
less
objects.
B
The
current,
when
you
say
the
current
realm,
the
key
thing
about
the
current
realm
by
the
by
the
by
the
primitive
promotion
is
that
current
is
syntactic.
It's
it's
the
code
that
contains
the
dot.
One
of
the
things
we
must
avoid
at
all
cost
is
dynamic.
Scoping
is
color
sensitivity,
so.
F
Sure
yeah,
I
see
this
is
kind
of
dynamic
scoping.
So
if
you
want
to
say
that
this
is
a
fatal
flaw
and
so
for
this
reason,
identity
subjects
don't
work.
I
would
understand
that
argument
as
well.
B
The
the
the
cases
where
there's
color
sensitivity,
that
is
observable
by
javascript
code
or
you
know,
I
think,
there's
one
minor
case
that
kevin
gibbons
identified
that
we
agreed
as
a
spec
bug
that
should
be
fixed
and
that
in
general
we've
you
know.
We've
we've
succeeded
at
avoiding
coral
color
sensitivity
in
the
javascript
language
and
we
must
continue
to
do
so,
but.
F
This
color
sensitivity
is
very
scoped,
and
it's
really
exactly
right.
You
know,
okay,
so
if
you
want
to
block
both
of
these,
I
really
want
to
see
more
on
the
membrane
side.
I
want,
I
think,
the
the
it's
not
it's,
not
a
web
compatibility
issue,
it's
a
it's,
maintaining
the
security
of
things
that
actually
given
the
history
of
it
probably
aren't
secure,
because
these
old
membranes
do
have
security
issues.
I
I
do
think
I
mean
I.
A
E
Incredibly,
user-friendly
compared
to
not
having
prototypes
for
sure
for.
F
A
I
think
that
it
could
be
made
the
tuples
being
struck
like
positional
struct
likes
might
not
need.
I
mean
I
agree
that
they
would.
It
would
be
useful
to
have
a
prototype,
but
I
I
don't
think
that
it's,
it
kills
the
idea
and
there
might
be
an
avenue
to
explore
there
if
it's
impossible,
to
avoid
having
dynamic
scope
revealed.
F
A
I
mean
yeah,
if
that's
being,
if
that
being
the
case,
then
maybe
there's
also
the
if
it's
also
if
there
are
other
reasons
why
it
avoids
dynamic
scope.
I
think
that
that
avenue
continues
to
be
viable
point
direction
for
further
exploration.
E
To
my
knowledge,
having
looked
at
a
few
of
these
dynamic
scoping
things
on
the
web,
this
does
not
introduce
a
new
one.
We
do
have
some
dynamic
scoping
on
the
web
with
the
incumbent
realm
stuff.
E
B
The
dot
accessory
I
agree,
but
but
that,
but
that's
not
the
only
issue
here.
E
E
B
E
Currently,
executing
you
have
an
execution
context
in
javascript,
it's
got
an
associated
realm
with
it,
and
so
that's
gonna
give
you
whatever
your
dot
access
accessor
does
as
a
prototype.
If
you
look
up
the
global
prototype
for
number
or
whatever
I'm
unclear
on
how
you're
accessing
so,
if
you
have
nested
realms
on
the
web,
there
can
be
realm
a
and
realm
b
you're
executing
in
realm
b.
I
do
know
there
are
ways
to
access
realm.
A's.
E
Primordial
object.
Wrapping.
E
F
F
Well,
yeah:
we
we
couldn't
make
them
type
of
object,
but
then
still
have
like
a
syntactic
rapper
thing
going
on,
but
we
could
have
you
know
we
could
have
special
logic
and
get.
I
don't
know
a
point
of
order.
I
think
that
we're
about
to.
A
Lose
quorum
since
we're
over
time.
I'd
like
to
call
good
point.
D
A
Yeah,
do
we
want
to
continue
having
this
conversation
next
week.
E
I
think
just
I,
I
only
am
really
interested
in
continuing
it.
If
we
can
find
that
this
introduces
a
new
kind
of
dynamic
scoping.
That's
not
true
for
the
other
primitive
types.
A
Probably
wise
because
at
least
you
and
myself
will
not
be
able
to
attend
yeah,
let's
make
another
official
and
then
the
week
after
that
is
probably
yeah.
It
is
definitely
tc39.
So
the
next
two
weeks
of
cess
meetings.
We
should
cancel
now
I'll
make
a
note
of
that
in
the
minutes,
all
right,
I'm
gonna,
I'm
gonna,
stop
the
recording.
Thank
you.