►
From YouTube: SES Meeting: Deep Equality and Shadow Realm Stack Traces
Description
Daniel Ehrenberg joins us to inquire about our thoughts on deep equality as a language feature and we discuss prose for eliding stack traces when they pass through the callable boundary of shadow realms.
A
Welcome
to
the
assess
meeting
today
is
August
31st
of
2022..
We
have
three
topics
on
the
docket
today,
where
we've
we've
drummed
up
three
topics
out
of
the
thin
air,
the
first
of
which
is
to
discuss
deep
equality
and
then,
secondly,
exceptions
and
struck
and
Shadow,
Realms
and
third,
the
shape
of
the
module
Constructor
continued
Daniel
brings
questions
about
what
what
would
we
want?
What
would
we
be
looking
for
from
a
deeper
quality
operator.
B
Yeah
I'd
I'd
say
there's
clearly
broad
demand
for
EP
quality
operator
in
JavaScript.
Both
of
you
look
at
you
know,
assertion
libraries
and
testing,
but
also
in
records
and
tuples.
We
have
DP
quality
just
for
records
and
tuples
would
it
be
feasible
to
have
a
general
purpose,
maybe
maybe
a
standard
Library
function
or
maybe
even
an
operator,
wait
to
check
if
two
values
are
deeply
equal,
including
support
for
cursing
into
things
like
objects,
arrays,
Maps
and
like
what
were
the
requirements
on
such
an
operation,
be
Is.
It
feasible
to
to
standardize
something
here.
A
B
C
So
I
can
speak,
so
we've
done
pedagoric
a
lot
of
engineering
within
the
context
of
the
semantics
of
our
distributed
object
system
and
how
that
reflects
into
conventions
for
using
the
local
language
to
create
a
system
in
which
we
do
have
a
deep
and
quality
operator,
and
it
is
very,
very
principled
and
has
very
clear
semantics,
and
but
it's
it's,
this
clear
semantics
comes
from
defining
a
semantic.
C
You
know
a
semantics,
that's
embedded
in
the
JavaScript
semantics:
it's
not
the
distance
between
it
and
just
normal.
Javascript
programming
is
not
trivial,
so
I
don't
know
the
degree
to
which
it
directly
in
answers
to
the
question,
but
it
certainly
is
very
clarifying
and
raising
issues
that
any
answer
to
the
question
must
satisfy.
C
So
the
the
main
problem
with
any
deep
equality
operator
for
JavaScript.
Is
that
there's
no
one
if
you
just
start
with
JavaScript
there's
no
one
objective
right
answer
to
the
question
of:
when
do
you
stop
rehearsing
and
compare
identities?
C
You
know
what
what
is
the
periphery
of
the
structure?
That's
compared
deeply
such
that
when
you
such
that,
when
you
get
to
the
periphery,
then
you're
comparing
it
on
other
criteria,
typically
identity.
C
So
what
we
do
categoric
is
we
have
a
the
sub,
the
subcategory
of
JavaScript
objects
that
this
all
applies
to
or
what
we
call
the
passables
and
the
passables
there's
several
different
subtypes
of
possible.
One
are
the
pass
by
copy
on
things
and
the
past
by
copy
things
include
copy
arrays,
which
are
just
regular,
JavaScript,
arrays
but
Frozen,
and
containing
only
passables
copy
records
which
are
regular,
JavaScript
objects
but
Frozen
and
containing
all
the
possibles.
C
We
do
have
copy
sets
copy
maps
and
copy
bags,
which
you
can
guess
from
the
pattern
already.
You
know
approximately
what
they
are,
but
but
they're
a
little
bit
more
specialized
than
that,
and
then
on
the
other
side
we
have
what
we
call
a
remotable.
C
The
term
remotable
comes
because
of
the
role
in
its
distributed,
object
semantics.
But
in
this
context
the
important
thing
about
a
remotable
is
that
it's
behavioral
is
that
it's
it
includes.
You
know
it's
odd.
It's
either
a
function,
a
function
can
be
a
remotable
or
an
object
with
methods
can
be
irremotable.
A
plain
object
that
inherits
from
object,
prototype,
that's
frozen
and
has
none
of
its
own
methods.
We
do
not
consider
to
be
an
object
with
with
methods.
C
From
this
perspective,
the
the
normal
thing
for
a
copy
record
is
to
inherit
from
object
prototype,
but
anything
that
has
further
behavior
the
that
further
behavior
is,
you
know,
functions
that
also
potentially
close
over
state.
So
things
with
with
you
know
whose
Behavior
can
depend
on
mutable
state
are
things
for
which
it's
very
problematic
to
think
about,
comparing
them
on
any
basis
other
than
identity.
C
There's
a
famous
old
list
paper
from
the
the
Golden
Age
of
lisp
called
equal
rights
for
functional
objects,
or
something
like
that
by
Henry,
Baker
and
Inter,
and
derived
from
this
a
equality
operator
which
was
basically
deep
on
identity-less
object
or
deep
on
identity-less
objects
that
had
no
mutable
State
and
then
identity.
Comparison
in
reaching
the
periphery
of
of
objects
that
had
potentially
variable
behavior
of
cost.
B
Yeah
I
think
that
that
sort
of
principle
makes
a
lot
of
sense
when
I
think
about
how
to
apply
things
in
in,
like
the
context
of
a
test
framework,
I
guess,
I,
see
more
sort
of
unprincipled
I
mean
I
I'm,
not
sure.
As
you
say,
the
distance
is
the
same.
That
sometimes
unprincipled
approaches
might
make
sense.
But
were
you
saying
so,
for
example,
you
could
imagine
stopping
you
could
imagine
comparing
their
own
properties
and
then
you
know
not
rehearsing
up
the
Prototype
chain
for
comparing
arbitrary
objects,
but
that's
completely
unprincipled.
C
Right,
so
the
thing
is
any
any
test
framework
is
that
just
has
like
a
deep
equal
built
in
it's
not
parameterized
is
going
to
be
compromised,
because
there
is
because
this
thing
is
they're
crying
for
one
answer.
That
applies
to
a
wide
range
of
JavaScript
programs
of
plain
JavaScript
programs
and
there's
no
one
additional
semantics.
That
plain
JavaScript
programs
agree
on.
That
gives
you
a
principled
answer
to
when
to
stop.
So
any
any
test
framework
will
adopt
some
answer
and
it'll
always
be
wrong
on
some
cases
and
experientially.
C
What
we
do
is
we
test
with
Ava
Ava
does
have
a
deep
equal
operator.
We
often
use
it
when
what
we
actually
should
be
saying
is
to
use
our
own
DP
cooperator.
C
It
often
works
well
enough
for
practical
purposes
for
us,
but
we
have
had
problems
with
both
false
positives
and
false
negatives.
I
mean
it's
surprisingly
rare
I
will
say,
but
we
have
had
both
problems
and
and
really
what
we,
what
we
you
know
the
ideal
thing
from
us
would
be
if
we
could
tell
Ava
up
front
for
our
use
for
for
programs
with
this
semantics.
What
we
really
want
to
use
is
an
evil-like
framework,
but
with
this
operator
that
we
provide,
as
the
VP
quality
operator,.
B
Okay,
so
one
more
question
before
we
go
to
Alex,
were
you?
Were
you
asserting
that
if
tc39
is
to
add
a
deep
equality
operator,
it
would
have
to
not
have
the
kind
of
pitfalls
that
Ava
has
I
mean
it's
kind
of
interesting
that
you're
still
using
Ava,
even
though
it
does
have
these
pitfalls
so,
like
apparently,
there's
some
demonstrated
value
in
the
not
perfect
version.
C
Yes,
yes,
and
with
regard
to
what
I
would
insist
on
a
tc39
I,
it's
let
me
just
say
it's
premature
for
me
to
yet
have
a
policy
or
opinion
about
what
I
would
insist
on,
but
I
would
certainly
want
the
issue
of
principle
versus
practical
compromise
to
be.
C
You
know
the
a
first
class.
You
know
the
The
Upfront
issue
to
be
invested
to
drive
the
investigation.
B
That
that
makes
perfect
sense
to
to
consider
the
trade-off
and
think
it
through.
So
it
sounds
like
you're,
not
you're,
not
saying
upfront,
it
has
to
be
completely
perfect,
but
that
we
should
really
when
we're
when
we're
making
compromises,
be
conscious
of
them.
Yes,
yes,.
C
Okay-
and
it
would
be
wonderful
if,
for
you
know,
just
as
an
example
of
a
principle
about
compromise,
is
if
we
have
sort
of
this
abstract
notion
of
what
principle
the
pro,
what
the
principle,
the
answers
would
be
that
that
a
compromise
needs
to
approximate.
It
might
be
nice
to
say
well,
this
compromise
only
has
false
positives,
or
this
compromise
only
has
false
negatives.
C
C
The
other
thing
is
that
the
collections
right
now
we've
got
maps
and
sets
in
JavaScript
and
maps
and
sets
are
themselves
have
a
wired
in
equality
operation
same
value,
zero
and
one
of
the
big
motivations
for
records
and
tuples
was
to
be
able
to
use
the
existing
maps
and
sets,
while
doing
structural
lookup
for
the
deeply
equal
things
by
simply
extending
the
semantics,
the
same
value
zero
to
to
be
deep
in
those
cases.
If
you
do
what
we're
talking
about
now
and
and
in
fact
what
agorix
did
that's
not
an
option?
C
What
you
need
to
do
is
build
new
map-like
and
set
like
collections,
which
we
call
map,
store
and
set
store,
and
and
then
we
have
a
a
a
our.
Our
passable
versions
are
passed
by
copy
versions
of
those
copy
copy
sets
and
copy
Maps
and
both
of
those
are
using
the
you
know
the
equality
operator,
that's
that
comes
from
our
distributed
object
systems,
both
so
all
of
those
abstractions
play
well
with
our
distributed
object,
system
and
I.
Think
that
that's
necessary.
C
Something
like
that
is
necessarily
going
down
this
route.
You
need
two
two
there's
two
issues
in
making
variations
on
maps
and
sets
forgetting
distributed
objects.
There's
two
issues:
one:
to
introduce
a
new
DB
quality
operator
is,
you
have
to
have
maps
and
sets
that
use
that
DP
quality
operator
on
their
keys
and
you
have
have
to
have
maps
and
sets
that
themselves
can
be
compared
deeply
and
therefore
can
serve
as
keys
in
such
maps
and
sets.
C
So
the
thing
kind
of
you
know
loops
on
itself,
which
is
you
end
up
with
maps
and
sets
maps
and
maps
and
sets
that
use
deep
equality
on
their
keys
and
that
themselves
are
keys
that
are
compared
deeply
in
such
maps
and
sets.
B
Yeah
I
agree
that
there
would
need
to
be
a
separate
kind
of
map
and
set
for
this.
I
have
some
more
questions,
but
I
want
to
go
to
Alex.
First,
okay,.
D
Okay,
I'm
gonna
play
devil's
advocate
here
and
I.
Think
I'm
gonna
poke
two
big
holes
in
this
idea.
So
please
understand
that
I'm
trying
to
help
but
I'm
trying
to
point
out
some
major
problems
here.
D
One
of
them
is
the
recursiveness
meant
thing
that
Mark
mentioned,
but
I'm
thinking
about
it
in
the
sense
of
axes
or
dimensions
of
recursiveness.
Let's
consider
we've
already
had
mentions
of
maps
and
sets.
We
have
to
think
about
object,
properties
prototypes
and
that's
just
inside
JavaScript.
If
you
look
at
the
Dom,
you've
got
siblings
and
previous
sibling
next
sibling,
which
are
properties.
You
have
the
owner
document,
which
is
the
property
you
have
child
nodes
and
parent
nodes,
which
are
properties.
You
have
attributes
which
are
properties.
D
D
Okay,
factoring
in
everything
that
I
just
mentioned
a
moment
ago,
that
means
that
for
any
kind
of
configurability
you
would
need
to
have
more
than
the
one
argument
that
you're
comparing
against
you
might
have
to
have
a
second
argument
or
a
third
or
whatever,
to
handle
various
other
various
situations
which
rules
out
an
operator,
because
the
operator
can
only
have
one
other
input
at
best.
I
think.
Unless
we're
talking
about
a.
B
D
D
Yes,
in
a
Dom
context,
but
also
in
the
terms
of
what
properties
we're
going
to
iterate
over
I
lost.
My
train
to
thought
give
me
one
moment.
Please.
D
No,
no,
that's
fine.
The
other
thing
regarding
an
operator
is,
we
already
have
double
equal
and
triple
equal.
D
I
would
not
like
to
see
a
quadruple
equal.
Oh.
E
B
D
B
A
A
concrete
example,
a
concrete
example
of
what
Alex
is
suggesting.
I've
implemented
the
Deep
equality
protocol
for
my
collections
Library
many
years
ago,
and
the
signature
of
a
deep
Quality
Function
was,
of
course
this
and
that,
but
then
also
an
ibid
table,
that
is
to
say,
answers
to
previous
equality,
questions
to
Short,
Circuit,
cyclic,
recursion
and
also
a
delegate
equality
for
the
children
of
the
thing
you're,
the
of
the
shallow
equality.
So
the
idea
would
be
that
that
each
object
would
be
would
Implement.
A
Each
object
would
Implement
its
notion
of
equality
on
its
own
on
itself
and
then,
and
possibly
even
have
a
Content
equality,
a
property
associated
with
it
for
the
default
indexing
for
that
for
the
children
of
that
collection,
but
but
that
the,
but
the
caller
of
the
deep
equality
operator
would
be
able
to
delegate
to
a
different
equality
comparison
for
the
children
for
complex
objects.
A
A
I
think
that,
by
way
of
a
counter
example
there
there
is
a
possible
if,
with
it
with
a
deep
equality
operator,
what
you
are
doing
is
blessing
a
particular
kind
of
deep
equality
which
I
think
is
appropriate,
possibly
and
certainly
necessary
for
the
case
of
keys
of
a
collection
again,
unless
you
created
a
more
sophisticated
collection
that
respects
the
that
respects
it.
Deep
equality
protocol.
D
One
last
thought
before
I
before
I
Surrender
the
the
floor:
I
forgot
to
mention
weak
maps
and
wheat
sets
deeper
quality.
There
I
don't
see
that
being
possible.
So.
B
I
think
for
for
both
weak
maps
and
dumb
nodes,
the
appropriate
DB
quality
operation,
just
like
for
functions,
would
be
to
compare
by
identity.
So
it
is
one
of
these
things
where
you
bottom
out,
as
Mark
said
that
doesn't
seem
especially
hard,
but
something
like
do.
We
allow
the
DB
quality
operation
on
mutable
arrays.
That's
something
that,
like
all
the
testing
libraries
allow,
but
with
respect
to
what
Mark
was
talking
about
for
principles,
it's
completely
unprincipled,
because
the
Old
State,
so
sorry
karate.
You
have
your
hand
raised.
E
The
rain
in
the
case
of
objects
that
will
have
internal
State
via
VIA,
a
private
fields
and
such
what
will
be
the
comparison
in
that
case,
you
just
skip
those
and
just
focus
on
on
the
regular
Properties
or
what?
What
is
the
semantic
for
that.
B
Yeah
one
one
unprincipled
answer
that
might
work
well
in
practice
would
be
to
say:
well
the
default
is
you,
you
skip
those
and
you
just
compare
the
public
things
and
then
any
object
can
override
that
I.
Don't
think
we
could
switch
to
Identity
based
comparison
just
because
it
contains
a
private
Fielder
method,
because
that
would
violate
the
the
principle
that
you
know
it
should
be
an
implementation
detail
to
add
a
private
field
or
method.
You
shouldn't
change
the
external,
visible
interface.
B
A
C
Right,
so,
if
you
are,
if
you
weren't
raising
your
hand,
I
do
have
more
to
say
on
this
topic
with
regard
to
what
the
criteria
is
for
finding
you
know
a
compromise
or
a
or
a
proposal
that
that's
solving
a
real
problem
for
us
here.
I
think
that
there's
two
very
different
starting
points
that
takes
that
that
are
kind
of
both
both
in
this
conversation
that
we
can
separate
one
is.
C
If
we
had
that
equality
operator
for
the
right
you
know
for
for
for
a
good
answer
for
deeply
Frozen
objects
that
it
could
recurse
into
the
objects
and
that
we
had
maps
that
were
that
used
that
as
comparison
for
key
lookup,
if
we
had
all
of
that,
it
could
be
very,
very
narrow
and
still
be
a
competitor
to
records
and
tuples,
because
records
and
tuples
are
are
only
extending
quality
in
a
very,
very
narrow
way.
We
just
it
would
so,
for
example,
something
that
only
recognized
Frozen.
C
You
know
Frozen
arrays,
that
inherit
correctly
from
array.prototype
and
have
no
and
have
no
non-numeric
own
properties.
No,
you
know
no
additional
name,
Zone,
Properties
or
symbol
symbol
named
on
properties
and
that
have
no
holes,
basically
just
the
the
simple
array:
cement,
simple
Frozen
array,
semantics
that
corresponds
to
what
a
tuple
can
express
and
likewise
with
records
that
you
have
you,
impose
a
set
of
constraints
and,
in
fact
our
distributed
object
system.
C
Consider
something
a
coffee
record,
or
copyright
in
fact
does
impose
all
of
the
constraints
that
correspond
to
the
semantic
constraints
on
records
and
tuples.
A
record
has
to
we.
We
made
one
compromise:
it
has
to
inherit,
either
from
null
or
from
object
prototype
we
allowed
both.
We
could
revisit
that,
but
it
has
to
to
only
have
all
of
its
own
property.
It's
it
doesn't
support.
C
Further
inheritance
of
all
of
its
own
properties
can
only
be
string
named
innumerable
with
the
other
constraint,
the
string
named
in
the
innumerable
own
properties,
so
that
all
of
the
the
different
owned
property
enumeration
operators
in
JavaScript,
which
there
are
a
tremendous
number,
all
give
the
same
answers.
C
And
you
could
say
that
if
you
only
wanted
to
compete
with
records
and
tuples,
you
could
say
that
these
very
constrained,
arrays
and
records
are
the
ones
that
are
first
inspected
for
conformance
to
all
of
these
constraints
and
because
Frozen
is
one
of
the
constraints.
We
know
that
that
car,
that
that
conformance
to
these
constraints
is
permanent,
that
it's
that
it's
a
stable
property.
If
you
ever
conform
to
the
constraints,
then
you
will
always
from
then
on
conform
to
the
constraints,
and
at
that
point.
B
Good
I
I
think,
even
even
if
we
went
in
this
direction,
I
think
we
would
still
want
to
maintain
like
the
Tuple
glass,
the
Tuple
exotic
object,
Behavior,
where
it's
not
gonna,
take
numbered
properties
and
delegate
to
the
Prototype
chain.
For
that
we
would
still
want
the
Tuple
methods
to
produce
tuples
instead
of
arrays.
We
would
still
want
to
have
a
record
Constructor
that
that
that
can
produce
these
things.
B
We
still
want
the
objects
to
be
Tagged
so
that
they
don't
require
recursion
to
go
into
them,
but
still
yeah
they
could
be,
they
could
be
objects
in
this
case,
sorry,
this
is
me
being
pedantic
about
the
scenario
yeah.
C
Yeah
the
thing
about
the
inherit,
inheriting
from
not
you
know,
numbers
inheriting
from
the
Prototype.
What
I
always
forget
until
I'm
reminded
is
that
for
JavaScript
as
a
whole,
we're
also
talking
about
a
language
in
which
object.prototype
and
array.prototype
are
mutable
and
can
have
you
know,
properties
they
didn't
start
with,
and
that,
of
course
violates
a
lot
of
the
assumptions
that
that
we're
making
we're
able
to
make
for
our
hardened
JavaScript.
But
in
any
case
the
the
so
so
many
guys
I
wanted
to
draw
a
dichotomy.
C
So
one
one
side
of
the
dichotomy
is
one
where
the
recursive,
the
criteria
that
do
you
recurse
or
not,
or
are
as
narrow
as
possible,
and
intended
only
to
emulate
the
cases
that
come
up
with
records
and
tuples
and
the
other.
The
other
part
of
the
dichotomy
is
what
the
testing
libraries
do
and
the
testing
libraries
would
be
useless
if
they
were
I
mean
they're,
deep
equality
operator
for
trying
to
codify
that
provide
something
in
common.
C
None
of
them
would
accept
something
that
narrow
all
of
the
current
tests
that
they're
doing
if
they
adopted
something
that
narrow
for
the
thing
they're
currently
in
deep
equal.
That
would
just
get
massive
testing
so
codifying
that
practice
versus
trying
to
absorb
the
virtues
of
records
and
tuples
into
objects
are
I.
Think
just
two
very
different
ways
to
approach
this
and
I:
don't
think
they
mix.
A
Okay,
the
second
topic
on
the
agenda
was
what
progress
has
been
made
on
handling
exceptions
through
Shadow
realm
boundaries.
E
Oh
as
a
me
and
as
I
mean
I
need
to
to
get
back
to
that.
Hopefully
this
week
that
doesn't
look.
I
have
a
lot
of
time
this
week,
but
we'll
see.
E
E
I
I
think
I.
Remember
adding
the
the
handle
on
the
three
places
that
we
call
the
the
wrapping
mechanisms,
I
believe
and
then
going
there
and
then
I.
Don't
remember
the
details
of
what
we
were
planning
to
do
there,
but
either
we
can
chat
about
it
and
I
can
rebuild
that
meta
model
or
you
can
help
that
the
same
and
again
well.
B
Yeah
I,
don't
think
I'll
have
time
to
like
write
the
spec
text
this
week,
but
like
once
you
have
it
written.
Then
you
know
being
me
and
I'm
happy
to
review
it.
E
B
E
Remember
it
was
in
the
three
places
we
were
planning
to
do
a
a
branch
branch
in
the
logic
there.
If
I
remember
correctly,
and
then
we
were
saying
that
Eve
every
throw,
then
we
were
going
to
call
a
new
answer
corporation.
That
would
basically
create
a
object
that
is
suitable
for
the
foreign.
B
Yeah,
let
me
talk
through
what
the
suggestion
was
really
quickly.
The
idea
was,
when
you
have
an
exception
thrown
in
a
shadow
realm,
whether
that's
based
on
importing
a
module
either
if
it's
errors
that
are
thrown
by
the
JavaScript
spec
or
is
there
to
thrown
by
executing
the
JavaScript
or
when
calling
a
function.
That
is
from
the
other
side
then,
and
then
there's
the
the
third
case
where
there's
a
the
function
is
being
called
kind
of
I
mean
there's
two
different
cases
of
functions
being
called
so
in.
B
In
both
those
cases
you
I
mean
in
all
three
of
those
cases.
You
catch
the
error.
You
know
the
current
logic.
B
Is
you
catch
the
error
and
you
replace
it
with
a
new
type
error
on
the
other
side
and
the
New
Logic
would
be
you
catch
the
error
and
you
replace
it
with
a
type
error
that
has
a
message
which
you
get
by
either
getting
the
own
property
and
checking
that
it's
a
value
and
then
copying
the
message
over
only
if
the
message
is
a
string,
if
it's
not
a
string,
you
you
also
discard
it
or
by
just
doing
a
simple
get.
B
I
think
last
time
we
talked
about
to
Matthew
and
and
I
like
we
hadn't,
really
reached
conclusion
on
which
of
those
two
it
was
I
mean.
We
should
quickly
reach
a
conclusion
on
that
question
here,
on
whether
we're
doing
a
normal
get
or
whether
we're
doing
a
get
owned
property
check
that
it's
just
a
value
and
then
use
that
my
rationale
for
just
doing
a
normal
get
was
like
you
know.
B
E
Normal
name,
that's
what
I
remember
yeah!
That's
what
I
remember
now
I
remember:
yeah
I
think
we
we
reply
to
do
just
again
and
then
get
the
feedback
on
the
pull
request
or
something
push
back
and
revisit
that.
Okay,
so
I'll
try
to
do
that
today
or
tomorrow.
So
then
I
think
it's
not
only
about
the
there's,
a
an
error
inside
the
shutter
run,
but
an
error
when
crossing
the
boundary
in
general
I
believe
yeah.
E
B
You
know
well
I,
guess
there
is
kind
of,
but
when
crossing
the
boundary
in
either
direction,
you
do
the
same
kind
of
wrapping.
That's
something
we
concluded
when
we
discussed
previously,
but
we
didn't
really
conclude
on
the
issue
about
whether
it
would
be
a
get
or
whether
it
would
be
a
you
know,
get
owned
property
checking
that
it's
a
value
Matthew.
Maybe
you
could
summarize
your
current
thoughts
here,
so
we
could
draw
a
conclusion.
F
I,
honestly,
this
is
a
little
bit
outside
of
my
brain
right
now
and
I
I.
Don't
have
my
thinking
on
this
page
then
currently
yeah.
E
B
Okay,
that
sounds
great
and
yeah
and
I
had
before
dropping.
B
A
E
B
F
Yeah
and
please
tag
me
on
that-
I'll
try
to
pitch
my
reasoning
back
in
and
see
and
and
go
back
to
the
recording
and
see
what
we
discussed
last
time
as
well.
D
B
Yes,
that
was
that
was
asked,
and
my
recommendation
is
that
we
say
specifically
that
stack
traces,
don't
cross
the
boundary
I'm,
not
sure
exactly
where
or
how
we
should
say
it,
but
I
think
we
should
be
clear
rather
than
ambiguous,
stack.
Traces
would
leak
too
much
information,
at
least,
if
they're
at
least
stack
traces
that
all
engines
provide,
which
give
you
introspection
to
the
stack
frames
that
give
you
access
to
the
functions.
That
would
be
a
realm
leak
right.
C
Maybe
hold
on
the
V8,
their
stack
traces,
give
you
access
to
the
sloppy
functions,
I'm,
not
aware
of
anybody
other
than
V8.
That
gives
you
any
that,
when
the
stock
prices
give
you
any
access
to
the
functions
and
even
V8
does
not
give
you
access
to
strict
functions.
B
Well,
okay,
great
but
like
it's
Shadow
Realms,
allow
you
to
run
sloppy
mode
code
right,
okay,.
B
So
the
you
know,
the
implementer
is
requested,
guidance
and
I
think
we
should
give
them
guidance.
Nv8
is
like
the
most
popular
way
of
JavaScript
engine,
and
we
should
give
them
guidance
here
about
whether
to
include
them
or
not
like
you
could
have
Sloppy
mode
code
running
outside
the
shadow
realm
and.
B
It
to
leak
those
functions
into
the
the
strict
one
into
the
into
the
shadow
realm,
so.
B
B
B
Have
already
so
I
think
we
should
I
I
wouldn't
be
opposed
to
even
normative
text.
That
says,
like
you
know,
if
an
implementation
has
some
kind
of
mechanism
for
introspecting
the
stack
trace
it
shouldn't,
you
know,
expose
the
functions
or
shouldn't.
You
know
some
something
like
that.
Whatever
whatever.
E
F
I
know
Alexis
is
interest,
but
I
would
like
to
quickly
clarify
this.
The
mechanism
that
that
V8
has
or
and
and
I
would
assume
any
other
engine
would
end
up.
Having
requires
the
doesn't,
it
require
objects
to
be
directly
reachable,
which
would
be
prevented
by
hopefully
the
invariance.
We
when
we
add
them
that
objects
from
another
realm
cannot
be
accessed
well.
I
accepted
their
earlier
zero
and
blah
blah
blah,
but.
B
So
I
mean
I,
think
you're,
saying
that
you
know
not
providing
the
stack.
Traces
is
a
theorem
that
can
be
proven
from
the
from
the
you
know,
desirable
properties
that
this
that
are
already
articulated
yeah.
That's
true
I
think
we
should
just
state
that
theorem
there,
rather
than
ask
people
to
redrive
it,
because
if
we
ask
people
to
redirect
it
they're
going
to
come
to
Divergent
answers.
F
Okay,
so
basically,
what
we
need
to
have
is
a
normative
note,
saying
stating
all
the
invariants
and
then
the
editor's
notes
clarifying
that
because
of
those
invariants,
the
stack
Trace
kind
of
this.
This
yeah.
B
A
F
Need
normative
spectacles
that
that
solidifies,
the
invariance
about
observing
an
object's
identity
through
across
Realms
when
a
shadow
realm
is
involved,
there
is
an
open
issue
for
that,
and
I
I
will
block
anything
if
that
is
not
included.
F
B
Okay
and
then,
but
what
about
what
I
was
proposing
in
addition
to
that
normative
text
that
says
normative
text
that
says,
by
the
way,
if
you're,
exposing
a
stack
Trace
like
do
or
don't
do,
XYZ
e.
F
C
I'm
I'm
confused
the
the
discussion
with
V8
about
clarifying
the
implications
on
about
their
their
idiosyncratic
V8.
Specific
stack.
Trace
notion
can
just
be
a
discussion
with
VA.
There's
no
reason
for
it
to
have
any
presence
in
the
spec
at
all.
The
spec
can
just
have
the
invariant,
and
then
we
can
explain
to
V8
what
the
implication
of
the
invariance
is.
I,
don't
see
why
that
explanation
has
to
have
a
presence
in.
B
The
text
my
experience
in
ESX
was
that,
when
these
discussions
happened
in
tc39,
where
lots
of
intentions
about
what
the
specification
were
were
communicated
out
of
band
to
people
involved
in
implementations,
is
that
it
didn't
connect
through
to
then
some
of
the
people
who
did
the
actual
implementations,
who
just
read
the
spec,
for
example,
nxb
3.3.
It
was
said
clearly
in
the
meetings
like
oh
yeah,
by
the
way
like,
of
course,
you're
going
to
do
other
stuff.
B
The
sloppy
function
hoisting
thing,
so
they
just
they
just
go
to
ESX,
just
codified.
This
minimal
intersection
semantics
that
was
not
even
really
expected
to
be
web
compatible
where
engines
were
expected
to
just
continue
doing
some
of
their
own
things
and
that
really
confused
us
I
think
we
should
just
write
things
in
the
spec.
If
it's,
what
we're
hoping
that
implementations
do
even.
B
F
I,
don't
think
we
should
single
out
stack
traces
in
the
normative
section
and
we
can
just
clarify
when
we
talk
about
rewrapping
these
errors,
like
because
of
because
of
that
other
more
General
normative
section
about
what
hosts
are
allowed
to
do
or
not.
Do
the
hosts
cannot
expose
stack,
Trace
information.
B
Yeah
as
long
as
we're
Concrete
in
saying
that
then
and
not
just
expect
everybody
to
derive
it,
then
I
think
that's
great.
C
Okay,
also
just
the
Matthew.
Maybe
it
was
a
slope
of
the
time,
but
I
want
to
make
sure
we're
distinguishing
two
very
different
issues.
The
what
Matthew
just
said
was
expose
information
and
whether
there's
information
exposed
by
the
stack
traces
I
think
is
an
independent
issue
from
whether
the
object
graphs
get
mixed.
Yeah.
Okay,.
C
I'm,
not
convinced
I,
mean
I,
think
it's
plausible,
but
it's
already
the
case
that
stack
crisis
exposed
non-local
information
and
that
there
are
and
that,
and
that
also
that
in
practice,
there's
when
we
say
stock
prices,
there's
actually
two
different
things
that
we're
talking
about
practically
one
is
what
you
get
in
the
language
from
the
error:
object
by
by
error.stack
or
whatever,
and
the
other
thing
is
what
you
see
in
a
debugger
stack,
trace
and
I
would
and
the
key
thing
about
the
second
one
is
the
second
one
can
include
a
lot
more
information
than
would
be
safe
for
the
first
one
to
include
there's
no
safety
issue
in
the
debugger
view,
presenting
more
information,
and
there
would
be
a
severe
functionality
loss
if
the
debugger
stack
Trace
did
not
follow
the
actual
execution
stack,
even
as
it
went
back
and
forth
between
realms.
B
B
B
C
B
D
I
just
wanted
to
finish
my
thought
regarding
the
stack
traces.
The
point
I
was
trying
to
raise
is
about
re-entrancy,
where
you
have
realm
a
calling
into
realm
B
calling
into
realm
a
and
then
you
have
an
exceptional
throne
and
with
the
stat
Trace
and
I'm,
not
talking
about
debugger
I'm,
not
talking
about
debugger,
but
with
the
stack
Trace
I'm
wondering.
Do
you
want
to
obscure
the
you
know
this
all
the
stat,
all
those
deeper
stack
frames
from
realm
a
and.
B
D
Okay
the
reason
I
bring
that
up
is
that
historically
in
the
Mozilla
realm
Mozilla
application
I
should
say
not
Mozilla
Realm
when
they
have
an
exception
thrown
from
native
code.
You
involving
this
re-entry
case.
You
do
see
those
stack
frames
in
the
stack
traces
that
they
provide
and
I
will
shut
up
now.
A
Okay,
so
first
off,
thank
you,
Alex
for
both
the
first
and
second
half
of
your
thought,
I'm,
sorry
that
we
spent
a
half
an
hour
on
the
first
thought
when
we
could
spend
a
half
an
hour
on
the
second
two
but
yeah.
Thank
you
for
bringing
both
topics.
They've
been
fantastic
conversations
and
that
with
that
we
are
coming
to
time-
and
this
is
also
fortuitous,
because
this
frees
charity
to
think
exclusively
about
Shadow
Realms
and
for
the
rest
of
the
week,
instead
of
paging
module
Constructor
into
memory
again.
A
So
perhaps
we
begin
with
that
next
week.
I
forget
whether
next
week
is
no
next
week.
Two
weeks
is
plenary
right.
A
So
see
you
all
next
week,
thank
you.