►
From YouTube: SES-mtg: Aug20 real title soon
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
Yeah,
so
we
were
talking
about
ergonomic
brand
checks
for,
in
particular,
this
ash
foo
in
object
and
in
a
previous
tc39
meeting.
You
mark
had
made
the
point
that
if
we,
if
we
I
mean
we
were
thinking
about
under
what
conditions
it
may
make
sense
to.
A
So
the
I'm
interested-
I'm
not
I'm
not
at
all
aware
of
the
recent
conversations
on
this,
so
how
people
reacted
to
the
membrane
or
how
many
of
that
conversation
went
I've.
No,
I
I'm
completely
ignorant.
B
A
Okay,
and
do
we
have
the
alex,
did
you
have
the
list
of
tc39
proposals
to
to
review.
C
Yeah,
they
were
just
further
down
in
the
agendas.
I'm
sorry
our
record
of
minutes,
simply
because
we
discussed
them
in
previous
meetings.
Okay,.
A
So
maybe
we
could
just
with
this
list
in
front
of
us.
Maybe
we
could
do
a
quick
triage
and
just
see
which
of
these
things
are.
A
Especially
relevant
to
discuss
and
then
just
and
then
having
collected
them,
then
discuss
our
overall
agenda
for
today.
Sure.
C
Okay,
so
the
first
one
that
I
had
listed
here
by
the
way,
I
just
took
a
look
at
the
list
of
proposed
discussions
for
the
september
meeting.
None
of
these,
as
far
as
I
know,
are
on
this
list.
Okay,
are
on
that
list.
I
should
say:
okay.
E
A
Yeah
about
half
of
the
agenda
of
the
meeting
actually
happens
on
the
day
of
the
deadline
to
post
their
agenda
items.
C
Okay,
okay,
so.
A
Good
good,
okay,
so
we've
got
so
so
we've
got
four
things
to.
Let
me
just
make
sure
I'm
not
dropping.
We've
got
four
things
to
examine.
There's
the
the
same
key
there's
the
reified
name
and
what
powers
it
should
have
there's.
What
was
it
that
you
just
mentioned
dan.
A
And
and
okay
and
then
there's
doing
a
triage
on
the
tc39
proposals.
A
Okay,
so
let's
quickly
just
eyeball
this
thing
and
anybody
speak
up
for
any
proposal-
that's
here
that
you
think
would
be
especially
the
opportunity
to
talk
about.
C
I'm
gonna
start
a
timer
just
to
make
sure
that
we
don't
lose
track
of
the
since
I
want
to
keep
it
for
30
minutes
or
less
to
let
other
topics
happen.
A
So
so
is
there
progress?
I'm
sorry,
I'm
sorry!
I
shouldn't
dive
into
it.
Yes,
we
should
discuss
that.
E
A
Okay,
so
of
the
things
here,
the
ones
that
I
think
well
there's
the
issue
about
what
to
talk
about.
What's
important
for
this
team
to
talk
about
in
general
and
there's
what's
what's
and
then
there's
waiting
that
by
urgency
of
what's
opportune
to
talk
about
in
this
meeting
since
this
meeting
has
now
has
very
quickly
a
substantial
agenda.
A
So
we
already
had
obsessed
read-only
collections
and
the
records
and
tuples
thing
and
the
same
key
thing
I
think,
will
all
end
up
being
closely
related.
So
I
would
go
ahead
and
keep
reading
collections
in
mind
when
we
as
part
of
the
discussion
about
records
and
tuples
and
same
key
the
fails
fast.
Not
this
meeting,
but
certainly
important.
B
C
A
So
I'm
going
to
do
the
read
only
collections
as
part
of
the
later
discussion
of
records,
tuples
and
same
key.
So
let's
so
so
chris,
it's
over
to
you
for
discussing
seth.
D
Sure
yeah,
so
the
cess
proposal
as
written,
is
very
stale
at
the
moment.
If,
if
I
recall
correctly,
I
haven't
looked
at
it
recently,
but
I
think
that
we
need
to
re-architect
the
cess
proposal
as
an
aggregator
for
its
composite
proposals,
realms
compartments,
etc
and
lockdown.
Yes,
and
then,
of
course,
the
compartment's
module
layer
which
might
be
separable
probably
is
separable
yeah
and
within
that
the
running
out
ahead
in
the
session
implementation.
D
There
are
a
few
noteworthy
changes
to
the
compartments
api
that
would
be
worth
discussing
in
this
meeting
like
the
addition
of
the
mod
well,
I
think
we've
already
discussed
the
module
method
pretty
thoroughly.
D
D
And
I
think
that's
where
it
is
at
the
moment
the
ses
shim
repository
itself,
its
documentation
tree
reflects
the
state
of
the
shim
when
it
was
based
off
of
realms
and
evaluators,
and
we
probably
need
to
recompose
that
in
in
parallel
yeah.
So
that's
that's
the
status
there.
I
think
and
of
course
volunteers
would
be
very
welcome.
A
So,
with
regard
to
the
api
changes,
would
you
like
to
or
project
something
to
look
at
with
regard
to
the
api
as
you,
I
would
like
to
say.
D
We're
supposed
to
keep
it
in
sync
with
the
implementation,
but
some
things
I
remember
and
some
things
I
don't
it's
a
new
thing:
oh
yeah
and,
of
course,
third-party
module
support.
We
should
discuss
here
too,
let's
yeah
the
mob.
Now
we
have,
we
have
nothing
to
share
the
module.
Map
hook,
isn't
documented
here
yet,
but
we
have
an
issue
for
it.
The
the
third
party
module
api
is
written
down.
Here
I
can
show
that.
D
Oh
no,
no!
Let
me
I'll
share.
D
D
Yeah
the
resolve
hook
would
fit
in
this
position.
Pardon
the
the
module
map
hook
is
an
additional
hook
here
that
serves
to
serves
as
a
fallback
that
makes
this
extensible
effectively.
D
The
third
party
module
support
that
we've
put
together
has
a
a
is
a.
It
changes
the
static
module
record
from
not
well
it.
It
extends
the
api
such
that
in
any
place
that
a
static
module
record
worked
before
a
static
module
record
implementation
of
that
interface
can
go
as
well
and
doesn't
have
a
complete.
D
It
doesn't
have
complete
parity
with
what's
possible
in
esm,
but
it
should
be
sufficient
for
common
js,
wasm
and
other
third-party
module
systems
that
don't
require
inter-module
live
bindings
and
within
that
subset
you
implement
an
object
that
has
an
imports
array
and
an
execute
method.
The
imports
array
is
used
by
the
loader,
regardless
of
whether
it's
an
implementation
of
the
interface
or
a
concrete
static,
an
opaque
static
model,
module
record
for
esm
and
then
on
the
execution
phase.
D
You
can
implement
an
execute
method
which
receives
the
the
proxied
exports
object.
D
Not
the
exports
proxy
object,
so
you
you're
getting
the
mutable
internal
view
of
your
module
namespace,
which
is
distinct
from
the
one
that
you
would
get
from
compartment.module
and
you
also
receive
the
compartment
object
and
a
map,
an
object
that
relates
the
imports
from
your
imports
array
to
the
corresponding
resolved
imports
in
the
context
of
the
compartment
that
you're
executing
in
which
may
vary
from
compartment
to
compartment
based
off
of
the
resolve
hook
the
yeah-
and
that
is
so
so
it's
your
obligation
within
this
execute
callback
effectively
to
to
punch
whatever
exports
you
wish
into
the
exports
object
following
the
conventions
of
esm
and
and
then
and
you
have
access
to
the
compartment,
the
containing
compartment
in
your
resolved
imports.
D
If
you
wish,
if
you
need
to
be
able
to
link
to
modules
in
the
same
compartment,
some
wiggle
room
exists
that
allows
you
to
import
things
that
are
not
actually
declared
to
be
imported
by
your
module,
which
is
something
we
might
want
to
clamp
down,
but
that
would
require
passing
something
other
than
the
containing
compartment
object.
As
an
argument.
D
Yeah
the
the
restrictions,
so
the
api
as
written,
is
in
in
session
today,
which
be
is
a
strong
end
for
the
proposal
is
that
you
receive
in
your
execute
function,
the
compartment
that
you're
executing
within-
and
that
is
a
cape
that
is
that
is
intended
as
a
capability
to
call
import.
Now
on
the
on
the
resolved
module
specifiers
corresponding
to
the
imports
in
your
imports
array,
but
it
doesn't
fall
it
is,
it
doesn't
constrain
you
sufficiently
to
prevent
you
from
importing
other
things.
A
D
D
Yeah,
which
is
I
I
I
ran
with
it,
because
it
was
simple
and
probably
not
a
problem.
It's
just
like
dynamic
import.
There's
nothing
preventing
you
from
using
dynamic
import
to
import,
something
that
wouldn't
that
would
it
would
fail
to
load.
A
That's
a
good
point.
Yes,
the
fact
that
that
dynamic
import
is
limited
only
by
your
compartment
does
kind
of
establish
that
as
a
unit
of
protection
for
importability,
the
compartment
is
the
unit.
The
module
is
not
the
unit
yeah.
A
So
so
you
know
so
I'm
having
the
same
reaction
that
this
is
fine.
The
on
the
live
bindings
I
wanna
has
anybody
here
ever
encountered
a
live
binding
in
the
wild,
something
that
somebody
was
actually
using
on
purpose
for
reasons
other
than
testing
the
mechanism
of
life.
A
Bindings,
okay,
I'm
not
surprised,
so
we
are
going
to
be
supporting
live
bindings
for
direct
esm
to
esm
linkage,
including
across
compartments,
but
we're
treating
it
as
a
anomaly
such
that
any
time
you
get
beyond
just
direct
esm
to
esm
we're
not
going
to
be
supporting
live
bindings,
and
I
think
that's,
I
think,
that's
that's,
probably
a
fine
place
to
stand
and
is
adequately
compatible
with
the
current
modulus
to
that
concurrent
atmosphere.
D
Yeah-
and
I
feel
that
if
we
attempted
to
create
a
first
class
or
second
class,
I
don't
if
we
were
to
create
an
api
that
allowed
third-party
modules
to
interact
with
live
bindings
that
there's
a
strong
possibility.
I'm
sure
that
that
would
interfere
with
the
way
esm
has
been
implemented
by
by
implementation,
since
they
are
at
liberty
to,
since
they
are
at
liberty
to
implement,
live
bindings
very
differently
from
our
shim.
They
can
a
native
esm.
D
D
A
Yeah,
I
just
wanted
to
double
check
the
semantics
of
having
a
record
argument:
the
module
map,
backed
by
a
function
just
to
double
check
my
understanding.
The
idea
is
that
the
record
provides
sort
of
a
first
declarative
statement
of
the
contents
and
then
the
the
the
function.
The
hook
is
a
procedural
extension
of
that
and
being
procedural
extension
can
therefore
be
lazy,
but
that
the
framework
around
both
the
object
and
the
function,
because
the
object
itself
can
also
not
be
declarative.
A
It
could
actually
be
a
proxy
or
the
properties
could
be,
it
could
be
accessor
properties
or
it
could
just
you
know,
be
mutated
while
in
progress
in
other
ways,
so
that
the
semantics
around
both
is
that
for
both
the
object
and
the
function,
it's
only
ever
asked
one
question
at
most
once
and
then
the
framework
memoizes,
the
the
answer
to
that
question.
So
that
question
is
never
asked
again.
If
you
never
asked
the
end
question
twice,
then
you
can't
get
inconsistent
answers.
D
That's
correct:
let
me
clarify
that
the
session
implementation
takes
a
snapshot
of
the
of
the
modules
object.
Initially,
I
will
have
to
verify
that,
but
I
believe
that
it
takes
an
initial
snapshot
which
means
that
it
it
it
exhaustively
checks
all
of
the
all
of
the
properties
of
that
object
during
the
constructor
and
never
asks
again
and
then,
if
there
is
anything
missing
in
there,
it
will
ask
the
question
of
the
module
map
hook
for
any
particular
key
once
in
that
compartment.
A
Very
good
that
lines
up
with
the
the
fact
that
you're
out
that
you're
walking
the
the
map,
the
declarative
map
up
front.
Do
you
know
how
that
aligns
with
what
model
implemented.
A
D
So
this
third
party
module
support
that
we've
added
is
a
sufficient
basis
for
us
to
create
an
interpretation
of
how
to
link
against
common
js.
D
However,
it
is
not
sufficient
to
create
an
interpretation
of
how
to
link
against
common
common.js
that
is
shared
with
node,
because
node
hard
stop
treats
common
gs
modules
as
a
synchronous,
loading
mechanism
that
can't
be
hosted
by
the
compartment
api,
and
on
that
note,
the
create
the
addition
of
of
top
level
of
weight
would
impact
this
api
for
third-party
modules.
As
specifically,
the
execute
method
would
be
allowed,
if
not
required
to
return
a
promise
there,
and
I
imagine
that
it
might
be
that
it's
be
it.
D
The
behavior
of
the
compartment
might
be
parameterized
on
whether
execute
returns,
a
promise
or
not,
so
that
it
can
detect
whether
the
module
is
using
top
level
of
weight
or
not.
My
understanding
is
that
esm
does
treat
those
cases
as
different
in
so
far
as
that
synchronous,
synchronous,
subsets
of
the
module
graph.
I
wish
bradley
we're
here
to
say:
oh.
D
Bradley,
I
believe
my
understanding
is
that
that
synchronous,
subsets
of
the
module
graph
that
can
be
executed
synchronously,
are.
F
D
Hi
and
it's
an
internal
slot
on
what,
on
the
space
object,.
F
C
Right,
gentlemen,
just
a
reminder,
we
did
want
to
talk
about
read-only
collections.
According
to
the
time
box,
I
proposed
we
have
just
over
11
minutes
to
do
so.
D
Okay,
cool:
I
think
that
before
we
discuss
this,
I
think
that
it'll,
it's
on
our
own
us
to
produce
pull
requests
that
we
can
look
at
together
against
the
tc39
proposal.
D
The
compartments
proposal
is
very
much
a
sketch
at
the
moment
so
before
we
make
progress
toward
advancing
or
make
progress
we're
discussing
at
tc39,
I
think
that
we,
you-
and
I
bradley
at
least
need
to
put
some
time
into
making
that
more
complete.
D
All
right
alex
the
floor.
I
give
the
floor
back
to
you.
A
Okay,
so
read
only
collections
and
how
this
fits
with
the
object
view
of
of
shallowly
immutable
identity,
free
objects
like
the
the
where
records
and
tuples
are
going
so
the
so.
The
idea
is
that
we
take.
We
take
this.
These
three
methods
snapshot
diverge
and
read
only
view,
and
we
make
them.
A
We
add
those
three
methods
to
all
of
our
normal
collection
types
and
what
a
normal
collection
type
is
is
something
to
be
negotiated,
but
it
includes
at
least
map
and
set,
and
if
you
do
a
so
right
now,
we've
got
the
only
maps
and
sets
we've
got
are
the
ones
that
are
mutable.
A
The
idea
would
be
that
if
you
do
a
snapshot
on
a
mutable
one,
that
you
get
a
shallowly
immutable,
one
that
is
structurally
compared,
and
this
really
forces
this
issue
of
the
conflict
between
order
insensitive
comparison
versus
having
keys
that
cannot
be
canonically.
Certain
maps
themselves
already
have
keys.
That
cannot
be
canonically
sorted.
The
the
keys
are,
you
know,
include
objects,
normal
objects
or
genuine
identity.
A
I
would
want
the
given
this
reconciliation
across
the
proposals.
I
would
want
a
snapshot
map
to
continue
to
have
all
of
the
same
keys,
but
be
compared
structurally.
So
obviously
the
structural
comparison,
that's
order.
Insensitive
cannot
be.
The
object
is
same
value.
Comparison
because,
because
same
value
implies
that
it's
computationally
identical
in
all
ways.
It
can't
be
an
observable
difference,
so
that
one
would
still
need
to
be
order
sensitive.
A
But
the
key
thing
is
that,
right
now,
all
of
our
well
all
of
our
normal
collections,
let's
say
meaning
maps
and
sets
compare
using
same
value,
zero
and
same
value.
0,
is
unlike
triple
equals
same
value.
0
is
an
equivalence
class
and
it
is
an
equivalence
class.
That's
less
precise
than
the
same
value.
We
fold
0
and
minus
0
together.
A
So
it
would
be
consistent
with
that
to
say
that
all
of
our
normal
collections,
where
they
currently
specify
same
value,
zero
instead
specify
same
key
and
that,
when
same
key,
is
applied
to
two
const
maps
to
snapshotted
maps,
that
it
does
a
structural
content
comparison
in
an
order,
independent
manner
and
and
therefore
you've
got
this
nice
sort
of
recursive
coherence
to
it,
which
is
the
collections,
are
compared
by
same
key
and
the
collections
compare
using
sync.
A
And
that,
if
we
do
that,
then
the
the
issue
of
allowing
symbols
as
keys
is
is
obviously
no
there's
no
way
in
which
it's
any
more
problem
problematic
than
allowing
genuine
object.
Identities
is
key,
so
this
would
take
care
of
both
of.
A
D
The
purpose
of
having
a
snapshot,
I
presume,
is
so
that
a
map
that
is
used
as
a
key
will
continue
to
be
able
to
retrieve
the
same
corresponding
value
regardless
of
any
well.
It
prevents
any
possible
mutations
that
would
cause
them
to
to
to
hash
differently.
A
Well,
also,
the
the:
if
it's
going
to
be
structurally
compared,
then
the
map
is
identical
to
a
copy
of
itself.
It
can't
be
distinguished
from
a
copy
of
itself
and
and
if
it
were
mutated,
if
then,
then
it
would
come
to
diverge
from
the
copy
of
itself.
So
the
idea
is
that
the
same
key
test
must
must
be
a
stable
test.
A
Anything
that
we
that
we're
going
to
use
as
an
equivalence
class
for
purposes
of
key
lookup
should
itself
be
a
stable
test,
so
that
two
things
that
would
you
know
where
one
key
would
have
looked
up
an
association.
A
mutation
should
not
change
the
key
in
such
a
way
that
it
no
longer
looks
up
the
same
association.
D
A
B
A
The
that's
a
very
good
question.
What
I
have
done
in
the
past
in
some
languages
is
to
actually
do
it
as
a
as
a
constant
or
log
time
operation,
and
I
would
I
would
encourage
at
least
no
worse
than
long
time,
but
I
would
not
mandate
it.
B
That
may
be
a
little
bit
challenging
to
transition
from
an
identity
based
object
to
an
identity-less
object
in
less
than
linear
time.
If
we
expect
reliable
hash
consent,
I
mean
we
could
do
the
hash
cleansing
lazily,
but
that
may
require
additional
indirections
in
the
you
know,
in
the
in
memory
format,
which
could
make
look
up
slower.
A
So
I'm
I'm
content
to
leave
this
to
the
judgment
of
implementations,
I'm
not
sure
as
a
standards
body
what
we
should
be
saying
about
what
things
are
expected
to
happen.
B
I
I
just
think
we
have
to
make
sure
that,
whatever
api
we
design
is
feasible
with
the
performance
that
use
cases
would
require
that
we
don't
design
something.
That's
so
fancy
that
it's
going
to
be
too
slow
to
make.
D
A
So
the
the
thing
that
I
think,
okay,
so
here's,
the
here's,
a
here's,
an
api
design
issue
that
I
think
determines
the
other
one
which
is
given
that
I
have
got
a
big
const
object,
big
shallowly,
immutable
collection.
A
Now
I
want
to
make
one:
that's
like
it,
but
a
little
different
if
I've
got
a
new
operations
like
a
analog
of
set,
that
makes
a
new
one.
That's
like
the
old
one,
except
one
one
association
is
different
and
that
those
things
are
fast.
A
A
Then
that
would
say
that
the
diverge
diverge
mutate
snapshot.
That
would
put
a
lot
of
pressure
on
that
to
be
cheap,
so
the
current
read-only
collections
proposal
does
not
actually
propose
the
functional
equivalent
of
the
mutation
operations
and,
I
think,
they're,
probably
a
good
idea
anyway
and
with
them
proposed.
I
would
not.
F
Yeah,
so
we
do
have
some
practical
experience
with
copy
operations
on
collections
being
problematic.
We
actually
do
quite
a
lot
of
copy
operations
of
set
in
particular
in
node
internals,
and
that
requires
us
to
essentially
do
a
linear
time
operation.
Currently,
it's
not
really
problematic
enough
for
us
to
complain
even
now,
but
we
could
avoid
the
entire
copy
operation
for
most
of
these,
when
we
know
it's
a,
I
don't
know
what
you
want
to
call
it
a
well-known
set
that
should
never
change
like.
A
So
what
what
I'm
suggesting
is
that
once
you've
made
a
snapshot
I'll
get
to
you
know
chris,
once
you've
made
a
snapshot,
then
you
have
what
I'll
go
ahead
and
just
call
a
const
set,
so
a
shallowly
immutable
identity
free
set
and
that
if
we've
got
these
functional
things
for
creating
a
derived
one
from
an
old
one,
that's
in
the
in
that
the
analog
of
the
mutation
operations
that
those
things
I
would
think
really
do
need
to
be
efficient.
They
really
do
need
to
be.
A
You
know,
expected
to
be
long
bounded.
You
know
not
proportional.
You
know
proportional
to
no
worse
than
the
log
of
the
size
of
the
set
and
as
long
as
that's
the
case
once
you're
in
the
cons
of
the
world
of
const
sets,
then
the
full
copy
to
get
from
the
normal
set
into
the
concept
and
the
normal
copy
to
go.
The
other
way,
the
the
the
overhead
of
the
snapshot
and
diverge.
Would
it
be
okay
for
those
to
be
full
copying
costs?
A
And
go
ahead
chris.
D
Yeah
I
had
a
very
simple
question
for
bradley.
Where
is
the
raise
hand
button.
C
Of
speaking
of
interruptions,
time
has
expired
on
the
on
the
proposal.
Reviews.
A
This
one
was
a
crossover
topic
anyways.
It
relates
to
the
to
the
whole
immutable
shallowly
immutable
object
thing.
D
Yeah,
while
this
conversation
was
going
on,
there
are
a
couple
of
pieces
of
well,
I
mean
the
hash
tries
are,
of
course,
a
very
reasonable
data
structure
for
the
snapshots,
since
they
have
that
property
of
being
able
to
do
fast,
mutations
to
immutable
objects
with
lots
of
shared
data.
D
So
I
imagine
that
this
yeah
I
mean
I
I
imagine
that
snapshots
carry
with
them
the
implication
if,
if
specif,
if
we
specify
a
set,
carry
the
implication
that
we
would
be
signing
up
implementers
to
to
implement
them
as
hash
tries,
the
another
thing
that
occurred
to
me
was
that
the
hash
for
a
map
could
be
incrementally
kept
up
to
date
in
a
way
that
is
agnostic
to
insertion
order
just
by
zoring
the
hashes
of
the
the
constituents
as
they
enter
and
exit
sort
of
as
a
a
cheap
but
symmetric
hashing,
algorithm.
A
That's
really
nice,
it's
not
just
that!
You
need
associative
and
commutative.
You
need
reversibility
and
xor
gives
you
all
of
that.
D
Okay,
cool
yeah.
I
wonder.
D
That
I
agree
that
yeah
well
as
bradley
was
saying
we
just
or
pardon
as
daniel
was
saying.
We
need
to
have
enough
in
the
footnotes
to
suggest
that
this
could
be
done
fast.
But
without
specifying
how.
G
B
Know
in
practice
this
works
out.
That's
something
that
I'm
trying
to
do
for
records
and
tuples
now,
and
but
that's
just
a
different
data
structure
from
read-only
collections.
You
know.
D
All
right:
well
then,
let's
return
to
the
agenda.
Shall
we
let's
see
let's
daniel,
do
you
have
we
given
enough
floor
time
to
the
topic
of
ergonomic
brand
checks,
or
is
that
something
that
we
can
revisit
now.
B
D
At
the
top
of
the
list
rolled
into,
I
assume
is
this
an
overlapping
topic
with
records,
tuples,
etc
records
toughness.
D
D
Cool
then,
let's,
let's
segway,
into
same
key
read-only
collections
and
records
of
tuples
in
whatever
order
the
floor
wishes
to
pursue
them.
E
A
You
don't
mean
key,
you
mean
order,
agnostic.
F
So
one
of
my
unvoiced
complaints
about
order
is,
if
you
get
a
record
and
you
add
a
field,
the
order
in
which
the
fields
in
particular
are
added
is
important
currently,
and
so,
when
you
are
not
really
mutating
but
producing
new
records,
you
have
to
be
very
careful
that
you
a
have
the
correct
ordering
or
b,
if
you
are
adding
a
field,
that
it
is
added
in
the
correct
place.
F
F
That's
always
easier:
let's
say
we
have
a
record
which
has
a
field
a
and
we're
adding
the
field
b
to
it.
F
So
now
we
have
a
record
a
b
ordered,
and
then
we
get
a
record
that
contains
b,
so
we
want
to
add
a
to
it
to
match
the
type
of
the
first
record.
So
now
we
actually
have
to
be
careful
not
to
append
to
the
one
that
only
contains
b.
We
must
produce
a
new
record
with
the
a
we
are
generating
and
then
append
on
to
it
afterwards.
B
So
I
guess
the
presumption
is
that
we
would
be
comfortable
with
this
approach
of
same
key
if
we
think
people
actually
use
triple
equals.
B
D
A
Yeah,
I
I
the
same
point
as
daniel,
but
I'm
confused
about
what
bradley's
saying,
because
it
sounded
like
he
was
broadly
I'm
confused
about
the
tense
of
what
you're
saying
the
right.
Now
we
don't
have
records
and
the
records
that
have
always
been
proposed
were
ones
that
would
compare
you
know
which
always
had
a
sort,
a
canonical
order,
independent
of
how
you
constructed
them
so
that
they
would
compare
in
an
order,
independent
manner.
So
having
the
records.
A
Compare
order,
independent
had
always
been
a
feature
and
same
key
just
makes
the
compare
order
independent
by
other
means.
So
I'm
not
sure
when
the
case
that
you're
worried
about
comes
up.
C
Yeah,
just
a
quick
clarification:
you
were
mentioning
a
pending
item,
appending
keys
and
values.
To
a
record,
I
thought
the
records
were
defined
as
immutable
and
to
begin
with.
A
Yeah,
making
a
new
one
derived
from
the
old
one,
we
do
need
better
terminology
for
so
to
always
speak
clearly
about
when
you're
mutating,
something
in
place
versus
when
you're
doing
incremental
derivation.
B
F
So
I
think
that
that
is
proven
false
by
the
ecosystem.
Already
with
objects
objects
do
have
well-defined
ordering
there
were
web
compatibility
problems
with
changing
it
to
not
a
long
time
ago.
I
remember
something
about
4n,
but
in
reality
the
order
in
which
fields
are
appended
to
objects
is
inconsistent
at
best
across
the
ecosystem.
I
don't
think
it's
something.
People
should
rely
on.
B
F
F
You're
saying
relates
to
records.
We
have
an
existing
example
of
a
structure
that
has
an
order
of
its
fields
objects,
even
though
the
programmers
could
rely
on
the
order
of
the
fields.
It
is
extremely
frowned
upon.
I
don't
know
how
to
put
it.
It
simply
isn't
unreliable
in
the
ecosystem
due
to
how
people
construct
objects.
B
So
I
guess
the
issue
was
fine.
I
guess
the
issue
was
when
you
have
keys
that
can't
be
compared
so
for
for
maps
that
are
deeply
immutable.
It's
kind
of
obvious
because
you
could
have
another.
If
you
have
a
complex
value
as
a
key,
then
those
don't
have
a
clear
comparison
function,
but
even
just
for
records.
We
have
symbols
as
keys,
so
we've
been
ruling
out
symbols
as
as
record
keys
because
of
this
uncomparability
issue,
and
if
we
relaxed
the
requirement
for
comparability,
we
could
have
symbols
as
record
keys,
maybe
just.
A
Just
to
clarify
terminology
you,
when
you
say
uncomparability,
they
are
comparable
for
equality,
so
I
think
you
mean
the
inability
to
order
them.
B
C
B
F
A
A
The
enumeration
order
is
always
deterministic
and
that
object
is,
is
still
a
precise
equivalence
class
that
always
distinguishes
things
which
are
observably
different,
so
that
so,
for
example,
two
records
that
were
the
same
according
to
the
same
key
but
had
different
enumeration
orders
would
still
be
distinguished
by
object
is,
and
I
think
that's
fine.
We
don't
have
any
collections
that
are
indexed
by
objectives.
C
I
I
don't
mean
to
ask
for
clarification,
but
I
missed
the
beginning
of
this
because
I
was
meeting
ran
over.
I
understand
same
key,
like
I
understand
what
you're
implying
by
it,
but
I
guess
I,
if
do
you,
have
a
10
second
summary
of
the
intent
behind
saying
like
why
we
would
want
to
move
the
same
key
beyond
like
what
it
does.
A
So
it's
already
the
case
that
our
normal
collections
maps
and
sets
index
according
to
an
equivalence
class
same
value,
zero
that
is
less
precise
than
the
same
value.
Less
precise
than
object
is
that
takes
things
which
are
observably,
observably,
different
and
folds
them
together
as
indexing
into
the
same
box
as
we
introduce
objects
that
are
shallowly
immutable
and
structurally
compared
rather
than
identity
compared.
A
That
introduces
a
new
case
that
the
collections
have
not
previously
encountered,
so
we
could,
without
breaking
any
compatibility,
replace
their
their
use
of
same
value,
zero
with
same
key
and
then
have
all
these
new
shallowly
immutable
objects
index
into
collections
according
to
the
same
key
equality,
giving
us
that
that
for
most
practical
purposes,
our
comparisons
are
doing
order,
independent
comparisons,
even
though
the
precise
observable
semantics
of
the
objects
always
continues
to
have
a
deterministic
order
and
that
those
deterministic
orders
enable
them
to
be
precisely
distinguished
using
objectives.
C
C
Regarding
the
sorting
of
symbol
keys,
just
as
a
as
an
aside,
I'm
wondering
if
it
would
be
practical
to
have
a
internal
slash
private
field
that
could
be
defined
for
symbol,
keys
and
just
be
an
a
number.
That's
incremented
for
each
individual
symbol
as
the
symbols
created
and
mark's
shaking
his
head
saying
hell.
No
okay,.
A
Right
that
hidden,
hidden,
mutable
state
covert
communications
channel
breaks
all
of
the
security
isolation
among
subgraphs.
Within
the
same
realm.
A
Doesn't
if
we
want
to
generalize
this
to
read-only
collections,
where
you've
got
the
keys
can
just
be
arbitrary
objects
with
identity,
then
making
some
special
case
for
sorting
symbols
doesn't
help
anyway.
A
Oh
while
richard
and
chip
are
both
here
and
we're
on
this
topic,
what
do
you
guys
think
about
adding
a
canonical
jason
stringify
to
the
language.
A
What
do
you
mean
by
that?
So
richard
has
defined
a
canonical
json,
meaning
that
the
semantics
of
jason
is
order
independent
on
the
keys
of
records
right.
But
given
you
can't,
if
you
had
a
way
to
stringify
an
object
graph
that
was
canonical
such
that
two
semantically,
equivalent
json
string
implications.
G
Had
yes
re-implement
this
myself
more
times
than
I
can
count?
Yes,
yes,
I
would
very
much
like
to
have
that.
A
Yeah
either
borrow
or
re-implement
it
again.
It
keeps
coming
up
and
for
security
purposes,
the
ability
to
say
all
semantically
equivalent
json
strings
can
be
hashed
to
an
equity
to
a
single
hash.
It
would
be
very
nice
and
you'd
like
to
do
that,
not
at
the
price
of
having
to
create
an
associative
community.
G
Right,
I
think,
and
I
think
I
think
I've
got
an
item
on
my
to-do
list
that
is
kind
of
never
making
it
to
the
top,
which
is
to.
G
I
think
I
think
at
the
a
a
meeting
a
while
ago.
I
don't
remember
whether
it
was
one
of
these
or
was
the
tc39
plenary
to
talk
to
richard
about
jason
apis
in
general,
but
I
think
I
think,
there's
a
there's
a
bunch
of
stuff
that
is
sort
of
just
there's
sort
of
this
cloud
of
dangling
issues
that
have
been
they're,
not
they're,
not
issues
with
jason
per
se,
but
with
the
json
apis
that
that
would
address
a
lot
of
the
things
that
people
whine
about
jason.
I
suspect.
G
G
My
only
concern
there
is
one
of
the
failure
modes
of
tc39
is
by
attacking
things
that
are
by
by
using
by
attacking
things
incrementally,
which
ought
to
be
tackled
holistically.
G
We
often
end
up
with
apis
and
specifications
which
are
considerably
more
complicated
than
would
be
ideal,
and
I
just
assume
not
start
another
one
of
those
exercises,
but
this
is
also
you
know
perfect,
as
the
enemy
of
good
problem
as
well,
and
I
think,
having
a
canonical
jason
stringify
would
be
good.
F
G
I
I
have
actually.
Yes,
I've
actually
done
that,
in
fact,
the
the
very
first
jason
handling
library
ever
written,
which
I
did
back
at
state
software
back
in
2001,
had
exactly
that
property,
which
was
just
because
the
use
case
we
were
using
it.
There
were
a
couple
of
fields
that
would
always
come
first,
and
this
is
strictly
just
to
make
things
clean
and
legible
for
debugging
purposes.
It
had
no
other
motivation
than
that,
but
so
having
had
that,
having
had
that
concern
emerge
early
makes
me
sensitive
to
it.
A
Okay,
right
now,
the
adjacent
the
the
javascript
json
api
gives
you
zero
control
over
the
order
of
fields
in
a
record.
A
G
G
C
A
Yeah
so
richard
you've
written
down
a
standard
for
a
canonical
json
serialization
I
mean
a
de
facto
state.
I
mean
you've
written
that
a
document
yes
and
you've
implemented
it
would
that
document
itself
be
suitable
for
dura
standardization.
E
G
Good
yeah
I
mean
so
so
I
guess
my
take
on
this
is
I
I
think
it's
a
fine
idea,
I'm
not
sure
what
the
action
item
is
and
if
so,
who
would
act
upon
it,
although,
if
richard
wants
to
push,
I
will
I
will
cheer
along
on
the
sideline.
E
So
yeah
the
the
possibilities
that
come
to
my
mind,
number
one
is
just
you
know,
propose
an
extension
within
ekma262.
G
The
404
specifies
the
the
format
of
the
json
text
itself.
It
has
nothing
to
say
about
apis.
A
That
is
that
actually
is
a
way
to
approach
canonical
json
as
you
could,
you
could
have
in
404
a
standard
for
this
is
what
a
json
string
in
canonical
form
looks
like.
G
Yeah,
although
I'd
I'd
rather
not
do
that,
just
because
we
we
had
to
do
a
lot
of
political
wrangling
to
get
the
ietf
and
ekma
on
the
same
page,
because
the
stuff
that
ietf
was
concerned
with
was
was,
from
my
perspective,
largely
irrelevant.
But
we
wanted
the
two
to
standards
documents
to
be
perfectly
consistent
with
each
other,
and
we
have
achieved
that
and
I'd
rather
not
open
up
opportunities
for
divergence.
G
And,
once
again,
I
think
I
think
I
would.
I
would
be
very
reluctant
to
make
any
changes
to
404
that
are
anything
other
than
clarifications
or
advisories.
G
Because
because
interoperability
across
across
time,
including
with
things
which
which
are
in
our
past,
is
important,
I'm
not
sure
I
mean
specifying
a
canonicalization
at
the
output
text.
Level
is
relatively
straightforward.
You
just
it's
essentially
two
things
you
get
rid
of
all
white
space
outside
of
string
literals
and
you
require
property
names
to
be
in
unicode
lexicographical
order,
and
I
think
I
think
oh
and
there's
probably
one
or
two.
E
G
G
G
Yeah
yeah,
I
think
I
think
the
way
that
markham
phrased
it
was
a
canonical
jason
stringify,
which
is
something
which,
when
given
an
object
tree,
will
produce
a
predictable
output
text
when
subjected
to
json.stringify.
E
G
E
I
don't
know
what
does
anyone
else
have
thoughts
on
the
best
avenue
for
pursuing.
E
G
Yeah,
that
would
be
my
first
choice
as
well
and,
as
I
say,
I
have
this
constant
approach.
Avoidance
thing
that
is
partially
driven
by
being
over
overly
time
committed
with
too
many
projects
on
my
plate,
and
so
it
never
gets
to
the
front,
and
the
other
is
is
things
that
I've
wanted
it
to
do
for
a
long
time
and
get
you
know
tripping
over
on
my
own
feet.
G
As
far
as
the
the
list
of
things
you
want
versus
the
list
of
things
that
are
easy
to
do
quickly
and
the
things
list
of
things
that
I
want
have
a
lot
of,
and
this
needs
to
be
figured
out
steps
in
them,
which
means
they
could
take
indefinitely
long
to
get
resolved.
A
So,
despite
chip's
objections,
what
I
find
most
attractive
is
the
idea
of
starting
not
with
the
api,
but
starting
with
the
grammar
definition
is
to
make.
Let's
call
it
a
variant
of
404.
So
it's
not
part
of
404
itself.
There's
political
problem
with
that,
but
basically
something
that's
sort
of
using
the
language
and
structure
of
or
four
to
just
define
what
a
canonical
json
screen
is
where
clearly
a
canonical
adjacent
string
is
adjacent
string
and
then
and
then
that,
because
that
grammar
definition
does
is
language
independent.
G
Right
well,
one
of
the
things
that
that
that
I've
encouraged
people
to
do
is
and
and
this
this
applies
to
not
just
your
concerns
about
canonicalization
but
conventions
for
how
you
encode
things
which
fit
naturally
into
json
but
which
are
not
part
of
the
current
api,
including
things
like
how
you
would
deal
with
big
integers
or.
G
And
other
things
like
that,
where,
where
you
know
basically
exactly
the
set
of
stuff
that
richard
has
been
been
hammering
on,
where
you
can
say.
G
It's
essentially
a
not
exactly
a
language
binding,
say
from
javascript
to
json,
but
close
to
that
of
you
know
a
specification
that
says-
and
here
is
how
we
are
going
to
interpret
this
set
of
javascript
things
as
json
and
having
just
a
standard,
essentially
serialization
spec,
which
which,
which
expresses
how
different
types
and
different
values
get
get
represented
in
this
form,
basically
a
a
formal
mapping
as
opposed
to
merely
what
what
the
the
current
json
api
spec
does,
which
is
mostly
concerned
with
the
programmatic
interface.
A
G
Launch
right
and
that's
see,
that's
something
that
drops
naturally
into
the
api
side
of
things
where
you
have
a
a
parts2
immutable
or
parsed
to
structs
and
tuples
or
whatever
you
want
to
name
it
and
which,
in
turn
leads
kind
of.
Naturally,
to
wanting
to
have
some
of
the
other
things
that
you
we
were
talking
about
earlier,
where
you
have
the
ability
to
create
a
immutable
form
of
a
you
know,
thing
which
was
original,
basically
initialize
a
immutable
thing
to
be
the
same
as
this
immutable
thing.
G
But
now
it's
mutable,
but
it's
a
separate
thing
and
like
that,
but
but
having
a
a
parser
that
can
return.
G
Structs
and
tuples
is
an
obvious
thing
and
that
the
place
where
I
get
a
little
squirrely
is
the
the
list
of
things
that
you
might
like
to
have
in
your
toolbox
starts
to
grow,
and
so
the
api
complexity
starts
to
grow
and
there's
at
some
point
where
you
want
to
to
sit
down
and
say,
is
there
some
coherent
unifying
framework
for
thinking
it
all
of
this
to
make
it
more
easily
understandable
and
make
it
not
just
be
a
giant
bag
of
mud?
G
And
at
that
point
you
start
slowing
down
the
train
because
you're
now
you're
trying
to
make
it
pretty,
instead
of
being
a
giant
bag
of
mud
and
once
again
I
tend
to
get
wrapped
around
the
axle
load.
How
do
I
make
it
great
as
opposed
to
how
do
I
just
solve
the
problem,
and
you
know-
and
it
may
be,
that
we
just
end
up
with
you-
know
a
a
a
a
box
of
miscellaneous
json
api
and
that's
just
how
it
is,
but.
E
Yeah,
that's
the
person
I'm
taking
so
far.
You
know
my
my
definitively
out
of
scope.
Feature
point,
for
example,
has
been
streaming
like.
Yes,.
G
I've
actually
implemented
a
streaming
api
that
is
not
ready
for
prime
time,
I'm
sure
there.
If
I
weren't,
going
to
go
poke
around
on
npm,
I'd
probably
find
26
of
them,
but.
E
So
all
right:
well,
we
we've
def.
We've
ruled
out
at
least
as
a
first
choice.
Itf.
So
that's
that's
progress
in
itself.
E
I
have
a
preference,
at
least
at
least
back
to
canonical
form
of
it
being
language
independent
from
the
start,
which
I
think
I
think
goes
to
maybe
like
a
sister
document
to
how
much
trouble
so
yeah
so
like
so
leave
404
as
it
is,
but
introduce
another
one
under
the
same
working
group
defining
a
canonical
representation
of
arbitrary
json.
G
G
I
think
that's
a
fine
idea,
I
could
see
a
concern
is
that
it's
going
to
be
a
two-page
standards
document
and
people
are
going
to
ask
well,
why
don't
you
just
fold
this
in
with
404.
A
G
In
in
the
sense
that,
if,
if
you're
gonna
in
terms
of
what
is
the
meaning
of
this
grayson
text,
you
could
do
that.
I
mean
one
of
the
one
of
the
recurring
questions,
and
this
was
actually
one
of
the
points
of
of
of.
G
Let's
say,
discussion
between
me
and
some
of
the
ietf
folks
was
404
explicitly
takes
is
explicitly
agnostic,
which
is
to
say
there
is
actually
text
that
says
we
are
not
taking
a
position
on
this
with
respect
to
the
meaning
of
the
ordering
of
properties
in
an
object
and
the
what
you
do
if
the
same
key
occurs
more
than
once,.
A
G
And
and-
and
there
are
yeah
various-
this
is
a
point
of
potential
incompatibility
between
various
implementations
of
parsers,
because
some
of
them
will
take
whatever
it
saw
for
us.
Some
of
them
will
take
whatever
it
saw
last.
Some
of
them
will
throw
an
error.
G
Introduce
any
weird
it:
it
forbids
weird
edge
cases
which
parsers
might
trip
over,
but
it
does.
It
does
have
consequences
for
for
serializers
or
stringifier.
In
fact,
that's
kind
of
the
point.
G
You
know
and
in
in
the
sense
that
it's
it,
it
kind
of
falls
into
the
the
heading
that
you
call
normative
optional,
which
is
to
say
it
doesn't
actually
impose
a
constraint.
But
it
does
say
if
you're
going
to
do
this
thing.
Here's
how
you
do
it
to
remain
compatible
with.
A
G
Yeah-
and
I
think
it
would
be
a
very
since
since
you've
already
got
all
the
other
spec
spoiler
played
around
it
and
anything
I
I
mean
it
would
probably
literally
in
this
case,
be
half
a
page
of
text,
so
it
wouldn't
be
it's.
This
is
sort
of
like
we
just
first
of
all,
decide
what
we
want
and
then,
after
that,
it's
all
politics.
A
Okay,
what
are
the
other
agenda
items
we
have?
We
have
left.
D
Yes,
one
moment,
let
me
pull
up,
we
have
we've
gotten
through
same
key
reified
name
and
what
powers
it
should
have
are
records.
Tuples
are
objects
guards
and
our
relationship
with
the
security
technical
group,
and
we
have
just
over
a
half
an
hour.
Let's
call
it
a
half
hour.
A
Okay,
dan
has
there
been
any
any
further
progress
with
regard
to
forming
a
security
technical
group,
there
seemed
to
be
a
little
spurt
of
activity
after
one
of
the
incubator
meetings,
then,
as
far
as
I
can
tell,
everything
went.
G
G
By
the
way,
by
by
the
way
of
pedanticism,
the
t
in
tc
and
the
t
and
tg
are
different.
A
Okay,
so
does
anybody
has
anybody
else
been
at
all
involved?
In
anything?
That's
happened
with
the
security
task
group
since
that
initial
spurt
of
activity.
A
Michael
for
cara,
okay-
I
I
you
know.
I
think
that
I
think
if
this
group
does
happen,
you
know
this
group
here
or
assess
group
is
not
at
all.
You
know
specific
to
sex
per
se.
It's
about
all
sorts
of
security,
relevant
javascript
topics.
A
G
Yeah
I
mean
one
essentially
a
proposal
is,
is
you
know
one
level
we
just
declare
ourselves
to
be
pg
yeah
would
be
tg3,
and
when
that
has
been
floated,
there
have
been
a
few
people
who
kind
of
reacted
a
little
kind
of
to
that.
I
think
it.
It
may
end
up
by
de
facto
becoming
that,
because
these
committees
are
pretty
much
defined,
as
the
committee
constitutes.
Whoever
shows
up
for
the
committee
meetings.
G
G
Of
this
meeting
I
perceive
this
is
perception
that
there's
a
desire
to
discuss
security
issues
that
are
outside
of
the
scope
of
things
that
we
typically
concern
ourselves
with.
I
know,
for
whatever
reason
we
don't
concern
ourselves
with
them
either,
because
we
think
those
are
wrong-headed
ways
of
doing
security
or
because
they're
just
out
of
scope
for
our
mission,
but
whatever
that
is.
I
think
there
was
a
sense
that
people
wanted
a
form
to
talk
about
those
things.
Whatever
those
things
are
and
I'm
unclear
on
what
those
are.
A
Okay,
good
I'm
clear
on
one
of
them
I've
only.
I
only
heard
one
thing
that
I
understood
that
falls
into
that
category
and
I
think
the
only
reason
we
haven't
discussed
it
here
is:
it's
never
just
been
the
priority
thing
to
discuss,
not
because
it's
in
any
way
outside
of
our
interests,
which
is
natalie,
has
shown
that
the
high
performance
javascript
engines,
the
ones
with
the
jets,
have
lots
of
memory
and
safety
problems,
and
the
reason
why
they
do
is
because
javascript
has
many
many
peculiar
things
that
enable.
A
So
so
what
I
heard
was
a
strong
desire
to
reduce
the
case
explosion.
On
the
one
hand,
that
came
up
at
the
last
tc-39
meeting,
but
also
avoid
adding
things
to
the
case
explosion
in
order
to
make
the
implementer's
job
easier
and
less
likely
to
introduce
new
memory
unsafeties-
and
I
think
all
of
that
is
completely
within
the
appropriate
agenda
for
this
group.
G
Well,
I
think
I
think
yes,
although
I
think
one
of
the
things
that
comes
up
in
that
context
is
the
the
use
of
of
process
boundaries
as
an
isolation
mechanism
and
one
way
to
think
of
process
boundaries.
There
is
a
way
to
limit
the
blast
radius
of
exploits
of
memory
unsafety,
which
I
think
actually
there's
a
lot
of
kind
of
well-rounded
common
sense
in
that
I'm
a
little
bit
more
put
off
by
kind
of
a
well.
G
We
can't
do
this
correctly,
but
we
know
all
those
linux
process
guys
can
do
whatever
it
is
they're
doing
correctly,
which
kind
of
frightens
me
a
little
bit
the
presumption
that
this
other
problem,
that's
in
some
other
set
of
developers
domain.
G
G
Javascript-
and
I
think
one
issue,
one
question
there
is
I'd,
be
curious
to
know
more
about
these,
these
sort
of
violations
of
memory
safety
that
have
been
found
because
it
seems
like
every
one
of
those
is
an
exploitable
hole
for
somebody
to
do
something,
terrible,
even
with
process.
Isolation.
A
F
F
Patches
that
aren't
landing
because
browsers,
don't
use
apis
the
ways
that
some
server
hosts
do
well
so
there's
definitely,
I
feel
a
good
reason
to
get
people
involved,
and
maybe
they
don't
feel
like
they
want
to
join
an
existing
group.
For
whatever
reason,
I
think
if
we
want
to
co-opt
it.
However,
that
seems
fine
to
me,
but
the
clear
thing
with
this
group
in
particular
is
we
do
have
outside
guests,
which
I'm
unclear
if
a
task
group
could
sustain
that.
F
A
Okay-
and
certainly
I
you
know-
I-
I
consider
it
to
be
a
requirement
for
our
habitual
meetings
that
we
have
people
outside
t239.
Here
you
guys,
many
of
you,
many
of
you
are
on
call
right
now
have
been
extremely
valuable,
and
if
we
can't
move
the
whole
group
to
a
different
label,
then
we're
not
going
to
move
to
the
other.
G
There
there
might
be,
I
think,
the
one
one
constraint
there
and-
and
I
guess
daniel
has
has-
has
drifted
away
from
the
conversation
because
he
might
be
able
to
speak
to
this
daniel.
If
you're
there
speak
up
is,
is
if
it's
an
official
ecma
thing,
then
it
may
be
a
requirement
that
people
who
aren't
ekma
delegates
have
to
sign
the
the
the
whatever
it's
called
the
the
ip
release
form.
That
says.
G
Yes,
I'm
not
going
to
try
to
claim
ownership
on
any
of
our
discussions
here,
which
I
hope
it's
not
a
big
hurdle,
but
it
would
be
a
formal
process
boundary
that
we
would
be
imposing
on
people.
A
Alex
when
I
had
you
attend
the
ecmascript
meeting,
the
tc
39
meeting,
where
we
co-presented
on
membranes,
you
were
attending
as
an
invited
expert,
which
is
an
official
ecma
designation.
G
C
G
I've
gone
through
various
periods
between
jobs
when
I
did
not
have
any
formal
corporate
sponsorship
and
I
continued
attending
tc39
meetings
and
basically
isfon
just
said:
oh
yeah,
you
should
be
here,
and
that
was
all
it
took,
and
so
I'm
kind
of
maybe
this
is
just
showing
my
privilege,
but
this
just.
I
don't
worry
about
that.
A
I
would
be
happy
with
that
kind
of
informal.
You
know
informal
arrangement
as
long
as
we
get
to
actually
meet
the
way
we
want
it.
E
D
Yeah,
I
imagine
that
I
imagine
that
topics
that
that
meeting
may
in
may
include
modules
in
the
same
origin
policy
or
something
like
that.
I
suppose
that
we
will
want
to
be
there
yeah.
There
will
be
discussions
about
security
models
unrelated
to
object
capabilities,
but
are
still
language
relevant
or
may
become
language
relevant.
A
Yeah,
fortunately,
nobody,
including
even
chrome
team,
has
suggested
trying
to
get
language
support
for
the
same
origin
model.
G
G
C
All
right:
well,
we
have
20
minutes
left
in
our
calendar
time.
D
Yeah,
that's
guards
our
records,
tuples
are
objects
and
rayified
name
and
what
powers
should
it
have.
A
B
A
A
B
I'm
so
sorry,
I
I
think
I
I
didn't
sleep
well
last
night
and
I
I
fell
asleep
and
just
woke
up
so
I
yeah.
B
G
B
B
The
acceptable,
no,
it
was
a
very
interesting
topic,
but
what
was
our
conclusion
about
this
same
key
topic
that
it's
it's
feasible.
A
A
B
Well,
I
feel
like
20
minutes
is
just
not
going
to
be
enough
time
for
us
to
do
a
full
treatment
of
records
and
tuples
as
objects
versus
identityless
objects
versus
primitives.
So
you
know
that's
a
topic
I
really
want
to
discuss,
but
I
feel
like
we
might.
Maybe
we
should
just
go
to
another
topic
because
the
others
and
I
would-
and
in
particular
I
was
thinking
about
guards
because
I'm
just
really
excited
about
that
topic.
B
Like
I
read
the
old
pages
about
it
and
I've
just
been
thinking
about
it
a
lot,
and
so
I'm
curious
if
you
could.
A
Yeah,
I
would
certainly
you
know
like
talking
about
that.
We
have
not
talked
about
it,
for
I'm
not
sure
ever,
but
certainly
not
for
a
long
time.
B
B
One
thing
is
typed
objects
in
the
webassembly
gc
proposal
so
like
how
how
we
could
have
objects
with
a
fixed
kind
of
shape.
That
would
be
more
optimizable
and
more
typable
with
a
predictable
memory
layout
and
I
feel
like
guards
make
sense
as
a
as
a
kind
of
part
of
that,
both
that
they
would
maybe
have
guards
in
them
for
the
fields
but
also
form
their
own
guard,
so
they
could
maybe
be
used
as
a
field
of
something
else
in
it
in
a
typed
way.
I'm
not
sure
this
is
what
guards
were
intended
for.
A
Within
the
within
the
range
of
what
guards
are
intended
for
it
wasn't
it
was
not
the
emphasis.
B
Where
you
can,
you
would
have
the
parameters
and
return
values
be
be
guarded.
So
then
it
could
provide
more
kind
of
certainty,
and
I
was
also
wondering
about
kind
of
the
relationship
with
with
unsound
type
systems
like
typescript.
A
So
typescript
is
a
yeah
there's.
This
whole
typing
theory
of
typescript
that
has
to
do
with
you,
know,
type
checking
all
the
parameterized
types
and
all
that-
and
I
don't
know
that
theory.
I
know
that
it's
you
know
it's
as
with
many
types,
many
fancy
type
systems,
it
has
its
origin,
henley
milner,
but
I
just
I
just
don't
know
the
specifics
of
typescript
the
easy
case
that
all
of
these
have
in
common
is
just
tag
checking
of
the
root.
A
So
you
know,
if,
if
you
want
to
know,
is
something
an
array
of
t
for
some
arbitrary
t,
then
you
have
to
look
then
at
runtime
you'd
have
to
look
inside
the
array,
but
if
you
just
want
to
know,
is
it
an
array
and
then
later,
when
you
go
to
use
something
from
the
array
you
want
to
know,
is
that
particular
thing
a
t?
A
Then
you
could
do
that
essentially
by
just
shallow
tag,
checking
so
one
of
the
things
that
waldemar
and
I
in
in
the
combination
of
the
types.
Sorry,
a
combination
of
the
guards
and
the
crate
marks
is
the
guards
are
a
general
mechanism.
You
can
write
a
guard
to
check
something
shallowly
or
deeply,
but
then
the
trademarking
mechanism
is
specifically
for
declaring
shallow
constraints
and
then
doing
a
tag
check
to
verify
a
shallow
constraint
in
constant
time.
So
we
definitely
had
a
part
of
our
design
center.
A
You
have
to
do
this
deep
walk
of
the
data,
which
is
you
know,
linear
in
the
size
of
the
data,
and
then
people
have
tried
all
sorts
of
crazy,
optimization
tricks
around
that
which
have
generally
not
worked
out
well
to
the
point
where
hybrid
types
where
you've
got
soundness
of
the
check
types
in
an
overall
on
type
context,
has
gotten
a
bad
rep
performance
wise
and
if
you're
doing
just
just
the
tag
checking
of
the
route,
then
that's
introducing
only
a
constant
time
overhead
and
it
can
be
a
very
small,
constant.
B
B
Like
you
know,
we,
the
the
trademark,
wiki
entry,
was
written
before
we
added
private
fields
and
methods,
and
there's
been
all
this
discussion
of
private
fields
and
methods
as
being
brand
checks
themselves.
A
I
don't
remember,
I
think
these
are
excellent
questions
and,
to
a
large
extent,
in
the
modern
javascript
era.
I
have
not
revisited
our
thinking
about
trademarks
and
guards.
B
So
I
had
a
you
know:
I've
been
thinking
about
how
typed
objects
would
relate
to
the
webassembly
gc
proposal,
and
so
in
particular,
this
proxy
transparency
question
comes
up
and
so
concretely
the
webassembly
gc
proposal,
as
I
was
kind
of
hoping
that
typed
objects
could
have
a
data
model.
That's
in
correspondence
with
the
webassembly
tc
proposal.
B
I
I
think
it
could
be
really
good
to
review
that
proposal
like
with
this
group,
because
it
it
has
the
webassembly
gc
proposal
is
basically
you
know.
Webassembly
is
basically
another
programming
language.
The
web
assembly
gc
proposal
is
a
language
of
instructions
for
creating
and
manipulating
keep
allocated
data
structures,
and
it
has
a
very
nice
clean
type
system,
and
so
you
know
it's
all.
It's
all
completely
sound.
There's
downcasts
but
they're,
very
sort
of
concretely
easily
checkable
and
valuable.
A
B
Yes,
and
with
the
webassembly
gc
proposal
preserves
that
by
you
have
you
know
it
has
single
inheritance
objects
based
on
these
rtts,
which
are
runtime
types
which
it
uses.
This
optimization
mechanism
for
single
inheritance
object
languages
where
you
sort
of
have
an
array
of
an
array
of
tags,
and
you
can
check
if
one
type
is
a
subtype
of
another,
because
each
one
is
represented
as
an
array
of
all
of
its
super
types
by
the
depth
in
the
inheritance
hierarchy.
B
So
to
check
if
one
thing
is
a
subtype
of
another
thing,
all
you
have
to
check
is
well
if
one
is
longer
than
the
other,
then
does
it
at
its
index
equal.
What
the
other
one
is,
because
your
checking
is
one
of
prefix
of
the
other
anyway.
So
so
the
web
assembly
gc
proposal
sort
of
includes
this
pattern,
but
another
thing
that
the
webassembly
gc
proposal
includes
is
well
it
doesn't.
It
doesn't
include
proxies,
so
it
doesn't
include
that
there's
distinct
identities
that
are
in
the
same
they
would.
B
So
concretely,
you
can
have
one
structs
that
includes
another
struct
as
a
field,
and
when
you
get
that
inner
struct
out
of
the
outer
structs,
then
you
can
directly
know
that
the
struct
field
is
at
a
particular
offset.
A
I
think
so
this
is
all
this
is
all
new
to
me,
the
in
general,
with
javascript.
The
way
we've
been
approaching,
a
lot
of
you
know:
virtualization
issues
is
it's
okay,
if
virtualization
throws
you
on
the
slow
path,
so,
instead
of
so
as
these
concepts
appear
in
javascript,
I
would
hope
you
know.
I
would
very
much
you
know-
want
to
constrain
them
to
preserve
the
virtues
of
proxies,
but
the
kind
of
implementation
optimizations
you
have
in
mind.
Those
are
for
the
fast
path.
A
It
would
be
okay
if,
when
these
things
are
being
virtualized,
if
you
lose
the
benefits
of
the
fast
path.
B
B
B
E
So
I
tried
to
raise
my
hand
and
let's
say
yes:
we
want
javascript
to
kind
of
get
into
the
web
assembly
benefits
of
structures,
and
I
guess
if
nobody
else
objects
we
should.
Yes,
please
do
that.
E
Well,
the
whole
idea
of
of
being
able
to
use
javascript
with
the
power
of
webassembly
to
do
computational
science
and
get
rid
of
all
these
java
inspired
things
like
matlab
that
basically
come
with
a
big
price
tag
which
you
could
get
for
free.
If
javascript
did
that
this,
this
whole
area
of
you
know
moving
away
from
from
things
that
are
more
than
two
decades
old
and
bringing
that
to
the
web.
E
Finally,
would
really
be
where
I
would
love
to
see
you
know
the
web
going
personally,
I
think
it
opens
up
a
lot
of
possibilities
that
are
currently
only
being
met
by
tools
that
are
either
too
expensive
or
old,
or
both
so.
B
Yeah
yeah,
you
know
I'm
excited
about
this
too.
I
feel
like
I
haven't
given
a
very
clear
exposition
of
the
this
kind
of
conflict
that
I'm
trying
to
piece
out.
Would
people
be
open
to
discussing
this
further
in
a
future
meeting?
If
I
brought
you
know
more
more
clear
materials
to
discuss
it.
A
I
think
that
this
sounds
like
a
a
very
big,
an
important
topic.
It's
one
that
I'm
it's
sort
of,
I'm
feeling
one
of
those
cognitive,
dissonance
things
where
two
things
both
of
which
I've
thought
about
are
meeting
each
other
for
the
first
time
it
seems
like
I
haven't
thought
about
them
together
before
but
yeah.
This
is
a
big
and
important
topic
and
I
think,
having
a
meeting
which
this
is
the
central
topic
which
starts
off
with
an
extended
presentation
by
you,
if
you're
willing
to
do
that.
C
I'd
second,
that
simply
because
it
sounded
like
I
heard
three
or
four
different
concepts
colliding
and
I'm
totally
lost
on
the
last
10
minutes.
I'm.
B
Sorry,
yeah,
okay,
I'll
I'll
I'll,
definitely
try
to
make
this
more
clear
next
time
and
I'm
excited
to
to
bring
this
to
a
future
meeting.
But
I
also
do
want
to
come
back
to
the
record
and
tuple
object
question
as
well,
and
then
all
those
other
things
that
we
had
queued.
This
meeting
didn't
get
to.