►
From YouTube: SES Meeting: Boxes ad nauseam
Description
Mathieu Hofman and Daniel Ehrenberg lead a discussion on Boxes and their design trade-offs.
B
So
if
you
go
in
and
spread
a
record
all-
and
you
can
verify
that
what
you
get
from
just
the
spreading
is-
is
triple
equal
to
what
you
gave
it
to
what
you
spread.
Of
course,
if
what
you
spread
is
actually
a
proxy
of
something
that
will
give
you
a
real
record
and
not
a
proxy
of
the
thing,
so
you
will
be
able
to
realize
that
what
you
had
in
the
first
place
was
a
proxy
and
not
a
a
record.
B
So
if
we
move
away
from
like
trying
to
make
proxies
of
record
and
tuples
behave
like
records
and
tuples
like
their
identity
and
just
them
being
objects,
then
it
then
they're
just
any
other
object
that
has
the
same
content
as
a
record
in
tuple.
What
might
happen
is
that
their
prototype
might
actually
be
a
tuple
prototype,
but
again
you
should
be
able
to
construct
an
object
that
way.
B
Actually,
I'm
not
sure
how
that
would
behave,
but
you
you
have
the
instance
of
behavior
and
and
and
in
general,
like
a
full
membrane,
would
probably
create
a
proxy
for
the
prototype
object.
So
it's
not
really
a
problem.
You
wouldn't
be
able
to
re.
It
would
behave
like
an
object.
Basically,
in
the
context
of
membranes,
I
believe
we
still
do
want
to
be
able
to
efficiently
somewhat
efficiently
pass
records
and
tuples
through
without
having
to
go
and
deeply
find
or
and
by
efficiently.
B
So
what
I'm
suggesting
is
helpers
for
boxes
that
allow
to
find
boxes
in
a
record
or
temple?
However,
deep
they
may
be,
and
a
map
helper
to
be
able
to
map
a
box
with
another
box,
and
I
think
the
last
interaction
with
the
callable
realm
or
whatever
name
it
will
be,
would
be
maybe
to
have
boxes
of
functions,
be
automatically
replaced
for
a
box
box
of
an
exotic
wrapper
function.
So
the
same
way,
currently
you
pass
a
function
through
the
callable
boundary.
B
A
C
D
Now
so
before
we
go
down
to
the
rabbit
hole
there.
I'm
from
my
understanding
up
to
this
point
it
was
that
the
record
would
not
be
duplicated
when
going
through
the
the
callable
boundary
you
get.
The
record
on
the
other
side
is
when
you
try
to
access
something
out
of
the
box,
that
we
can
do
something
about
it
and
the
second
part
of
it
is
that
initially
we
say
well,
if
you
do
have
a
box,
then
you
cannot
send
it.
D
C
Sorry,
carry
that
doesn't
correspond
to
the
current
version
of
the
proposal.
The
current
version
of
the
proposal
is
that
it
would
throw
if
the
box
contains
an
object.
It
wouldn't
do
this
deferred,
deferred
error,
and
the
reason
for
that
was
because
this
round-tripping
concern
that
that
bradley
raised
that
you
know
you
can
kind
of
round
trip
an
object
if
we
allowed
that
through
a
box,
and
so
we
decided
to
just
be
more
restrictive
at
first
about
the
membrane
over
record
and
temple.
C
C
One
thing
is
that
it
would
return
true
from
like
record
dot
is
record
and
double
dot
is
tuple,
which
I
think
are
predicates
that
we
agree
would
need
to
exist,
and
the
other
thing
is
that
the
triple
equals,
or
that
is
based
structural,
deep
equality
works.
I
think
it's
important.
Those
are,
those
are
key
to
the
programming
model
and
and
membrane
should
should
work
with
them.
D
C
D
This
thing
sorry,
sorry
danny,
like
I'm,
trying
to
understand
so
based
on
the
idea
that
we
would
that
any
idea
that
we
already
agree
on
at
some
point
that
you
would
not
be
able
to
send
any
record
tuple
if
he
has
a
box
on
it.
Okay,
so
if
that's
a
case,
then,
when
the
record
goes
through
the
membrane,
while
the
expectation
is
that
the
record
will
just
be
passed
through
like
any
other
primitive
value,
you
don't
need
to
throw
a
proxy
around
it
is
that
it.
C
No,
the
no
the
expectation
is
written
in
nicolo's
document
is
that
if
it
contains
a
box
that
contains
an
object,
then
you
have
to
eagerly
convert
it.
So
I
liked
the
idea
from
matthieu's
exposition
that
we
could
have
some
way
to
look
through
some
nested
records
and
tuples
and
find
all
the
boxes
containing
objects
all
these
exit
points
and
map
them.
So
right
now,
that's
possible
to
do
manually
eagerly
and
what
I
think
what
we
would
want
is
a
way
to
do
this
lazily.
C
So
what
if
we
had
a
form
of
record
or
tuple
or
box
that
was
like
well,
this
is
a
mapped
record
or
tuple
or
box.
So
when
you
access
it,
when
you
reach
one
of
these
exit
points,
then
if
it's
the
first
time
you
reach
one
of
these
exit
points,
then
a
function
gets
applied
to
the
contents
of
the
box
or
it
gets
applied
to
something
I'm
not
sure
exactly
what
the
contents
of
the
box.
I
guess
that
doesn't
really
work
because
you're
on
the
wrong
side
of
the
membrane.
Already,
oh.
A
A
So
I
have
two
mappings
just
like
we're
talking
about
right
now
and
when
you
go,
and
you
actually
want
to
look
up
the
value
of
that
symbol,
it
fires
a
trap
which
is
essentially
a
getter.
It's
not
as
full
featured
as
a
getter.
It
just
causes
you
to
reify
the
identity
and
once
it's
reified,
it
never
changes.
A
So
it
sounds
like
similar
to
what
I'm
doing
here.
We
want
to
perform
a
map
operation
on
a
record
or
tuple,
which
is
a
deeply
immutable
data
structure,
and
it
has
some
small
parts
of
it
which
we
want
to
lazily
compute,
the
value
of
when
they're
accessed
and
those
need
to
be
accessed
in
order
to
form
an
identity.
A
C
Well,
then,
we
have
a
choice
between
either
we're
going
to
trap
the
either
we're
going
to
do
what
you
suggested
and
say.
Well,
these
are
just
no
longer
records
and
tuples.
They
don't
have
this
identity
or
we're
going
to
have
to
force
the
entire
thing
whenever
the
identity
is
needed.
Yeah,
I
don't
think
there's
a
third
path.
E
E
But
it's
shadow
because
the
properties
point
at
correspond.
You
know
the.
If
the.
If
the
real
target
is
yellow,
yellow,
then
the
shadow
target
is
blue
and
the
the
properties
of
the
real
target
point
at
other
yellow
objects.
The
property
of
the
shadows
target
pointed
other
blue
targets,
which
is
why
there's
a
shadow
target
now
the
gedonka
experiment
is
in
the
case
where
there
is
no
distortion.
E
Do
you
need
a
a
proxy
on
the
shadow
target,
or
could
the
blue
object
corresponding
to
the
yellow
real
target?
Could
the
blue
object
instead
just
be
the
shadow
target
itself?
In
other
words,
having
constructed
the
blue
shadow
target
to
represent
the
yellow
real
target
is.
Are
you
if
there's
no
distortion
is
any
purpose
being
served
by
wrapping
a
proxy
around
the
shadow
target,
rather
than
just
using
the
shadow
target?
E
E
E
D
E
Yeah-
and
I
think
I
think
I
think
that
I
think
that
breaking
the
lazy,
I
think
of
all
the
things
we
need
to
break
here.
I
think
the
lazy
creation
is
the
thing
is
the
thing
that
we
can
most
afford
to
break
and
because
there's
no
cycles,
it's
just
an
issue
of
taking
the
cost
upfront
versus
spreading
it
out
over
time.
B
I
think
this
is
not
quite
what
I
was
saying,
so
what
I
was
saying
is-
and
I
think
we
all
agree
here,
since
there
is
no
way
what
I
said
is
like
a
proxy
in
front
of
recordable,
especially
if
it's
implemented
as
a
identity-less
object,
so
type
off
equals
object
will
always
be
observable
as
as
is
so.
The
only
path
that
you
have
at
that
point
is
to
eagerly
create
your
your
deeply
frozen
object
or
slash
record.
B
D
E
C
E
Points
as
well
about
how
some
of
the
other
solutions
here
break
some
things
that
I
think
we
desperately
need
not
to
break
for
for
reasons
much
deeper
than
you
know,
much
much
bigger
than
performance
reasons.
One
thing
is
identity.
Checks
must
be,
must
not
introduce
potential
interleaving
points.
A
trap
on
an
identity
check
introduces
an
interleaving
point
right
now,
where
javascript
is
safe
from
interleaving
points.
I
know
that
I
can.
D
D
To
I
was
trying
to
I,
I
feel
that
you
guys
are
a
lot
ahead
of
myself,
so
I'm
still
stuck
back
in
in
in
a
very
specific
question,
okay,
which
I
believe
correspond
to
what
mark
was
saying
and
the
the
the
description
that
you
gave
about
the
shadow
target
and
so
on.
So
I
want
to
see
you
can
help
me
to
clarify
what
the
position
is
there.
D
It
is
important
that
the
to
understand
that
the
callable
boundary
doesn't
give
you
access
to
both
sides
of
the
fence.
That's
the
principle
that
you
don't
have
access
to
both
objects
graph.
Therefore,
if
you
get
a
record
on
one
side
and
you
want
to
create
a
similar
record
on
the
other
side-
that's
problematic
on
itself
and
when
you
bring
boxes
into
the
picture
is
also
very
problematic.
D
I
I
believe
the
problem
the
it
might
be-
that
is,
efficiency,
is
one
of
the
problems
that,
but
I'm
not
sure,
so
I'm
trying
to
explain
what
what
I
believe
the
problems
are.
Let
me
explain
it
very
quickly.
So
if
I
get
the
record
here
and
I
detect
that
the
record
is
going
to
go
through
the
call
of
a
boundary,
I
need
to
do
some
operations
to
either
create
a
similar
record.
On
the
other
side,
somehow-
or
I
built
a
record
that
I
gave
to
you-
those
are
the
two
options.
D
D
A
C
C
Record
and
temple
proposal
says
you
cannot
transport
them
across
the
boundary
if
they
contain
a
box
that
contains
an
object,
and
you
can
if
they
don't
contain
a
box
that
contains
an
object.
So
the
way
that
to
get
back
to
matthew's
question
about
efficiency
is
the
way
that
the
record
and
trouble
proposal
enables
efficiencies
by
providing
this
operation
to
check
whether
you
deeply
contain
an
object.
This
is
where
we
came
to
in
the
discussion
a
while.
D
C
C
D
C
Deal
so
when
we
have
boxes,
we
pass
it
over
in
piece
by
piece
and
when
we
don't
have
boxes,
then
we
pass
the
whole
thing
over.
So
the
the
case
with
boxes
is
just
like
when
you
have
an
object
and
want
to
kind
of
represent
it
on
the
other
side,
and
you,
you
know,
pass
over
different
incremental
pieces
of
information
in
terms
of
primitives.
C
B
Which
yeah,
so
I
think
the
problem
in
what
I
presented
earlier
is
that
I
went
straight
to
my
conclusion
without
going
through
the
steps
of
my
thinking
last
week,
and
I
probably
should
have
gone
through
that
to
help
answer
a
lot
of
charities
and
mark's
questions.
So
basically
we
all
arrived
at
the
same
conclusion.
You
need
to
eagerly
recreate
the
structure.
On
the
other
end,
the
immutable
structure.
B
Exotic
wrapper
so
now,
when
it
gets
on
the
other
side,
the
other
side
can
go
in
and
create
a
proxy
with
just
that.
It
doesn't
have
to
eagerly
go
deep
in
that
in
that
proxy.
It
just
can
create
those
proxy
objects.
Those
exit
points
in
in
and
and
recreate
a
record
that
way,
so
that
that
is
the
eager
recreation
of
the
immutable
structure.
D
So
a
couple
of
comments
on
these,
so
the
efficiency
side
of
things.
I
think
we
could
kind
of
solve
it
somehow
I
it
would
be
tricky,
but
it
would
be
a
good
exercise
to
try
to
recreate
a
record
tuple
on
the
other
side
that
has
boxes
and
then
proxy
those
boxes.
Somehow,
on
the
other
side,
I
imagine
that
we
could
create
a
kind
of
a
a
a
record
that
where
the
box
exists,
you
put
a
symbol
that
you
understand.
That
is
a
symbol
that
needs
to
be
replaced
with
the
box.
D
D
That
seems
a
very
interesting
thing
to
me
to
explore.
I
feel
that
then,
the
api
of
determining
something
has
boxes
on
it
might
be
insufficient
because
you,
you
need
to
know
okay,
it
has
boxes,
but
add
those
boxes,
functions,
callables
and
then
go
and
do
a
a
a
a
a
type
off
or
something
on
all
these
things
to
see.
If
it's
callable
and
then
you
let
it
pass.
Otherwise
you
do
something
else.
I
rather
prefer
to
have
a.
D
We
tell
you
that
there
are
boxes.
We
tell
you
that
information,
you
decide
whether
or
not
you
wanted
to
pass
it
anyways,
you
pass
it
anyways,
you
try
to
access,
and
then
it
throws
on
axis.
If
it
is
not
a
a
callable
boundary,
it
seems
like
to
me
that
that
that
seems
a
little
bit
better
easier
and
more
efficient.
B
Wouldn't
the
membrane
always
even
for
a
function
always
create
a
proxy
for
that
function,
because
we
don't
know
what
might
be
attached
to
that
function
anyway.
So
for
the
efficiency
of
the
membrane,
the
membrane
would
go
in
and
no
matter
what
it
gets,
an
objective
function
or
whatever
it
would,
it
would
create
it
would.
Oh
yeah.
D
D
Sorry
just
to
answer
that
question
it
will
help,
but
you
still
have
to
traverse
and
create
a
new,
a
new
record
before
you
let
the
record
to
pass
through.
Like
you
had
the
arena
yellow
record,
you
had
to
create
like
a
a
similar
to
a
shadow
target
as
a
shadow
record,
let's
say
shadow
record
that
one
has
to
have
the
the
the
the
the
same
shape.
But
then
you
have
to
change
the
boxes
with
the
proxies
of
the
arena
box
value.
E
B
D
D
B
You
do
mapping,
so
the
the
membrane
on
one
side
does
a
mapping
of
all
the
boxes
that
contain
objects,
functions
or
whatever
to
the
special
membrane
function,
and
so
now
the
record
only
contained
boxes
of
the
membrane
function
that
can
be
used
that
can
be
transferred.
On
the
other
side,
it
will
be
exotic
wrapped.
On
the
other
side,
you
map
again
that
record
with
the
same
structure
again,
and
you
create
boxes
of
proxies
using
your
your
membrane
function.
That
has
been.
D
B
Yeah
advantage
is
that
if
you
keep
a
box
in
the
same
place,
you
keep
the
structure
entirely.
You
keep
the
structure
the
same.
You
just
have
boxes
with
different
content,
so
my
hope
is
that
the
engine
can
somehow
optimize
that
by
being
able
to
copy
the
structure
and
replace
the
content
of
of
the
boxes,.
C
Yeah
I'd
be
curious
to
understand
what
kind
of
optimizations
you
think
the
engine
can
apply
to
to
do
that.
I'm
also
curious
what
kind
of
api
you're
picturing
over
this,
and
also
it
seems
like
we're
in
agreement
that
this
is
a
potential
performance
optimization,
and
so,
if
it
is,
then
can
this
be
post
mvp.
C
And
finally,
I
want
to
say
that
this
this
mapping
of
boxes
does
relate
to
feature
requests
that
we've
heard
from
other
people,
where
some
people
say
that
they'd,
like
boxes
to
serve
this
kind
of
template
use
case
and
honestly.
I
still
don't
understand
this
use
case,
but
I
wonder
if
maybe
you
could
work
with
advocates
of
that
on
a
follow-on
proposal
to
that
would
enable
both
this
kind
of
templating
use
case
and
this
optimization
for
for
membranes.
B
C
E
B
B
C
E
C
Problems
with
this
one
problem
is
part
of
that
side.
Table
might
become
unreachable,
while
other
parts
are
reachable,
and
then
it's
unclear
how
the
engine
should
deal
with
that
and
then
the
other
problem,
which
is
more
basic,
is
okay.
Now
you
have
another
level
of
indirection,
and
so
getting
the
contents
of
a
box
becomes
like
one
extra
indirection
slower,
and
you
really
want
to
do
that.
D
D
E
D
Say
that
I
want
to
implement
some
sort
of
a
iterator
over
the
async
iterator
over
the
the
callable
membrane,
so
I
need
to
provide
some
metadata
about
what
position
I'm
in
the
iterator
and
so
on,
and
then
providing
maybe
the
functions
that
you
can
call
once
you
have
to
go
to
the
next
item
in
the
list
and
so
on.
So
you
have
to
provide
multiple
values
to
the
other
side,
but
the
problem
is
that
the
other
side
calls
you
once
and
receive
only
one
return
value.
D
The
return
value
could
be
only
a
primitive
value
or
a
callable,
but
you
want
to
provide
more
values.
You
want
to
provide
data,
some
primitive
values
and
a
function.
So
how
you
do
that
you
cannot
return.
You
have
to
go
multiple
round
trips,
just
to
get
the
information
that
you
want.
That's
one
of
the
problems
of
optimizations
that
we
have
today
with
the
with
the
implementation.
D
So
if
I
can
provide
a
record
that
contains
all
the
metadata
that
I
want,
plus
the
functions
that
will
do
the
operation,
some
coordination,
then
that's
easier,
because
I
just
produce
every
time
you
call
a
function
on
the
other
side.
That
returns
a
record.
That
record
contains
all
information
that
I
need,
which
is
primitive
and
all
the
functions
that
I
might
need
to
call
to
do
more
coordination
and
then
the
other
side
does
the
same.
So
the
coordination
becomes
a
lot
more
simple.
C
So
I
agree
that
this
would
be
nice.
I
guess
there's
two
parts
to
it.
One
part
is
ergonomics,
and
another
part
is,
is
performance
overhead
as
far
as
performance
overhead
goes
sure
yeah,
I
guess
doing
the
check
at
the
time
of
access
would
help
reduce
the
performance
overhead
of
like
having
two
function.
Calls
versus
one
function,
call
yeah.
I
don't.
C
D
I
mean
so
I
don't
know
I
I
don't
know
what
the
expect
the
core
instead
of
this
state
of
the
spec
for
recording
triple
h,
I
looked
into
it
for
sure,
but
if
the
access
is
simply,
if
the
record
somehow
or
the
box
somehow
has
information
about
what
rom
was
that
record
created
off
and
when
you
try
to
access
the
value,
we
apply
the
exact
same
routines
that
we
have
today,
which
is
just
saying.
Okay,
who
is
the
caller
a
record,
the
the
color
rom?
D
C
C
A
D
C
C
A
C
If
you
and
then
you
like,
pass
it
back
so
then,
if
you
invoke
that
identity
function
or
like
so
you,
you
have
an
identity
function
from
you
know
past
past
from
another
realm
or
you
so
it
so
it's
going
to
do
this
callaway
boundary
thing.
Basically,
it's
just
an
identity
function
with
the
caldwell
boundary
applied
with
with
the
callable
boundary
like
double
applied.
C
So
if
you
pass
a
a
primitive
to
it,
okay,
you
get
the
same
primitive.
If
you
pass
a
box
to
it,
yeah
you
get
the
same
box
back.
If
you
pass
a
function,
you
don't
get
the
same
function
back.
You
get
an
observably
different
function
because
it's
wrapped
twice,
and
so,
if
you
pass
a
box
that
contains
a
function
and
you
look
at
what
it
contains
well,
this
is
kind
of
asymmetrical
that
it's
not
containing
the
same
thing.
I.
D
C
D
C
A
D
A
D
Right,
but
I
think
we
passed
the
membrane
discussion
like
we're,
not
really
looking
into
the
at
least
I
wasn't
really
looking
into
the
membrane,
but
just
generic
communication
between
the
two
sides.
We
are
a
custom-made
protocol
that
could
be
the
membrane
protocol
yeah,
but
so
more
generic,
more
simple
one,
so
yeah.
So
I
like
to
understand
more
why
so?
Checkpoint
access
will
be
an
issue.
A
A
A
So
this
means
that
for
both
realms,
you
have
to
preserve
a
table
of
potential
incoming
things
that
need
to
be
mapped
to
their
counterparts
in
the
opposite
realm
doing
so
cannot
realistically
be
garbage
collected
until
the
entire
realm
is
garbage
collected.
Unfortunately,
or
any
communications
channel
between
the
realms
is
completely
cut
off
again.
A
A
C
E
C
A
E
A
E
This
all
comes
from
the
history
of
garbage
collection
concepts
in
the
e-language,
the
weak
maps
and
proxies
together
were
designed
exactly
to
enable
good
membranes
for
synchronous.
You
know
single
address
space,
garbage
collection
under
one
garbage
collector,
where
the
ephemeron
collection
logic
enabled
both
the
collection
of
cycles
that
cross
the
membrane
as
well
as
if
the
membrane
is
revoked.
Collecting
everything
within
the
now
inaccessible
object
graph.
E
If
you've
got
that
cycle,
but
you've
all
got
it
under
one
garbage
collector
we're
assuming
that
cycle
goes
away
now
for
the
distributed
case,
weak
maps
don't
help
at
all.
What
helps
what
helps
exactly
is
weak
references
and
finalization.
That
was
the
motivating
use
for
that
and
that
does
not
collect
cycles
that
collects
acyclic
distributed
garbage
at
electric
communities.
E
We
did
do
a
further
elaboration
which
we're
not
proposing
that
matthew,
amazingly
rediscovered.
I
think
almost
the
identical
logic
for
actually
described
in
this
in
a
substantially
simpler
manner,
but
we're
still
not
proposing
that
the
actual
experience
we
generally
have
with
distributed
garbage
is
distributed.
Garbage
is,
is
quite
often
a
cyclic.
The
fact
that
we
lake
distributed
cycles
so
far
has
not
bit
us,
although
at
some
point
I
expected
well,
but
that's
pr.
I
wouldn't
be
surprised
if
that's
decades
out
before
we
have
to
face
that
problem.
A
E
D
A
E
A
Just
not
hold
on
I'm
going
to
try
to
finish
the
example.
Okay,
sorry
so
so
you
have
fu
still
alive
for
whatever
reason
in
realm
a
it's
going
to
want
to
be
garbage
collected,
it
has
gained
a
reference
to
foo
prime
correct
and
then
foo
prime
is
held,
and
if
you
do
not
hold
both
weekly,
you
leak
memory,
so
foo
prime,
has
to
be
held
weekly
by
b
and
foo
has
to
be
held
weekly
by
a
in
order
for
a
cycle
to
be
collected.
That
means
fluke.
C
A
E
B
A
E
A
C
C
A
A
C
A
A
A
A
C
So
so
bradley,
I'm
I'm
on
board
with
you,
this
more
expensive,
pragmatic
definition
of
leaks,
and
I
guess
what
I'm
missing
is
your
your
history
and
experience.
Debugging
memory
leaks
in
practice,
so
the
example
of
okay,
you
have
a
static
property.
That's
that's!
On
the
function!
Yeah,
I
see
how
that's
unreachable
engines
might
be
able
to
be
taught
how
to
collect
that,
because
the
only
thing
you
can
access,
if
it's
wrapped,
is
its
callableness
yeah.
This.
D
D
C
C
E
Let
me
let
me
let
me
propose
a
level.
You
know
a
a
distinction
that
that'll
help
us
distinguish
what
level
of
ambition
we
should
be
shooting
for
and
what
level
of
ambition
we
should
not
be
shooting
for
without
any
boundaries
without
any
membranes
without
any
callable
boundaries.
Just
regular
javascript
in
the
software
engineering
sense
that
bradley's
talking
about
it's
leaky.
People
have
leaked
bugs
in
programs
because
they're
strongly
holding
on
to
things
that
they
didn't
notice.
D
C
C
C
But
another
example
of
where
this
comes
up
this
decision
about
whether
we
want
identities
to
be
shared,
maybe
a
more
profound
case
is,
is
multi-threading.
Do
we
want
to
I
mean
it
would
be
cool
if
records
and
doubles
could
be
shared
between
multiple
threads,
and
in
that
multi-threading
case,
should
we
allow
boxes
to
be
shared?
C
You
know,
the
easy
answer
is
obviously
no
on
the
web.
This
could
happen
sooner
than
later,
with
the
structured
clone
definition
for
records
and
tuples.
So
there
are
a
few
alternatives.
One
alternative
is,
you
know,
first
of
all,
I'm
not.
I
don't
think
the
web
is
going
to
immediately
embrace
multi-threaded
cycle
collection,
and
but
if
it
did
one
day
then
you
know
it'd
be
pretty
cool
if
we
could
have
boxes
to
represent
the
identities
in
in
records
and
tuples
and
pass
them
back
and
forth.
C
So
you
could
have
this
opaque
mapping
to
an
object
and,
and
so
as
a
as
in
your
term,
question,
there's
the
question
between
whether
putting
a
box
in
a
record
or
tuple
that
points
to
an
object
when
you
structure
clone
that,
should
it
throw
or
should
it
just
structured
clone
the
contents
of
the
box
and
throw
would
be
kind
of
the
answer
that
we
would
choose
if
we
want
to.
You
know
future
proof
ourselves
for
a
later
possibility
of
actually
just
directly
passing
the
identity
across
threats.
A
A
B
A
C
D
Yeah,
I
I
rather
prefer
to
just
to
spend
more
time
thinking
more
about
these
and
trying
to
figure
if
we,
if
we
could
do
this,
I'm
very
worried
about
the
efficiency
of
of
the
communication
between
the
two
realms.
When
you
have
records
on
tuple
and
the
complications
and
the
complexities
you
will
be
adding
the
ergonomics
of
it
will
be
horrible.
D
You
have
to
now
traverse
dick
traverse
reconstruct
the
record
without
those
things
and
and-
and
you
just
want
to
pass
something
to
the
other
side
and
then
do
more
coordination,
which
is
already
complicated
through
the
call
of
a
wonder
now.
You
have
to
make
it
for
records
and
tupo
would
be
just
a
lot
more
difficult.
Finally,.
E
Yeah,
korea,
I
have
a
question
for
you
something
I've
been
curious
about
that
bears
on
this
issue,
completely
forgetting
records
and
tuples,
just
with
the
existing
work
that
you've
done
on
the
callable
boundary
and
on
rebuilding
membranes
on
top
of
the
callable
boundary.
What
do
you
expect?
The
overhead
of
a
full
distortion
free
membrane
on
top
of
the
coral
boundary,
is
compared
to
a
normal
distortion,
free
membrane
without
a
callable
boundary
just
constructed
by
normal
means.
D
D
D
I
think
it
would
be
the
same,
because
the
same
concepts
can
be
applied
to
the
regular
ones
in
a
optimized
way
and
again,
I'm
talking
about
getting
a
membrane
that
is
sufficiently
strong,
meaning
you
never
leak
anything
to
the
other
side,
which
is
the
overhead
that
you
add
in
a
regular
membrane
like
you
have
to
put
all
this,
I
would
say
it
is
a
compensation
effort,
because
in
a
regular
membrane,
you
have
to
cover
all
the
cases
of
throwing,
on
the
other
side,
leaking
an
error.
Doing
all
these
things
in
this
one.
D
You
don't
have
to
do
that
because
that's
covered
by
the
engine
so,
but
you
have
to
cover
the
cases
that
you
don't
have
direct
access
to
the
target
on
the
other
side
and
so
on.
So
I
think
it
would
be
about
the
same
okay,
but
the
problem
that
we're
describing
here
is
what
words
means,
because
the
minute
you
add
records
and
tuples
to
the
equation.
Now
you
have
to
go
and
add
terms
of
complexity.
On
top
of
it.
C
Wait
but
records
records
and
tuples
are
handled
pretty
analogously
to
objects.
I
mean
there's
two
things.
There's
one
thing
you
were
talking
about,
making
a
more
ergonomic
way
to
communicate
across
the
boundary
using
records
and
tuples
as
an
implementation
detail,
and
I
think
we
would
be
saying
like
sorry
this
isn't
what
we're
getting
right
now.
D
C
D
You're
right
like
if
we
say
you
can
only
pass
a
record
that
doesn't
have
any
boxes
on
it,
but
when
you
are
constructing
a
membrane
that
doesn't
work,
you
have
to
build
the
record
on
the
other
side
equivalent
to
this
one,
and
that
complexity
has
to
be
added
to
the
membrane
implementation,
to
recreate
the
record,
with
the
boxes
peroxide
on
the
other
side
and
all
that.
So
I'm
worried
about
that
complexity
to
be
at
all.
E
C
A
E
Think
we
can't
do
it
lazily.
I
think
that
means
that
if
you're
only
going
to
touch
a
tiny
portion
of
the
structure
that
you've
paid
an
overhead
of
doing
eagerly
something
you're
only
using
a
small
piece
of,
but
that's
not
going
to
be
the
common
case,
and
if
you
do
eventually
use
all
of
it,
then
you
still
have
the
same
amortized
overhead.
You
just
took
the
hit
up
front
rather
than
spreading
it
out
over
time
and.
E
D
C
Access
really,
if
you
pass
over
recorded
tuple,
that's
like
the
thing
that
you
want
to
wrap
and
you
pass
it
over
the
membrane
boundary
and
you
expect
the
box
the
default
box
handling
to
do
something
meaningful
it.
Just
it
just
won't.
Do
anything.
Meaningful,
you're
gonna
have
to
transfer
the
contents
of
the
boxes
over
in
some
other
way,
so
you're
still
going
to
have
to
traverse
the
original
structure.
Yeah.