►
From YouTube: SES-mtg: sep 2 real title coming 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).
A
All
right
so,
let's
begin
with
building
out
our
agenda.
It's
currently
open
empty
on
the
document,
but
we
have
some
leftover
items
from
our
previous
meeting
with
daniel
that
we
can
advance.
A
Let's
going
over,
that,
we
have
the
topic
of
ergonomic
brand
checks.
B
I'm
not
for
ergonomic
brand
chicks,
I
guess
I'm
there.
There
were
a
bunch
of
different
topics
that
we
discussed,
so
I'm
not
sure
which
one
we
should
prioritize.
A
Okay,
so
let's,
let's
put
it
on
and
then
figure
out
what
order
it
fits
in
relative
to
the
others.
Okay,
so
the
other
one
was
same
key,
which
I
think
we've
discussed
briefly,
but
not
to
completion
the
reified
names
and
what
powers
it
should.
A
A
B
There
was
the
the
one
that
came
up
during
the
meeting
that
I
don't
think
was
on
the
agenda
last
time,
which
was:
should
we
use
a
separate
sort
of
expand
the
definition
of
same
value
zero?
Instead
of
doing
the
key
sorting
approach.
A
A
I'll
I'll
add
a
footnote
to
that,
so
that
it's
it's
it's
clear
that
they're
related
another
topic
was
guards,
and
I
think
that
those
are
the
topics
that
we
wanted
daniel
present
for
the,
of
course,
our
relationship
with
the
security
tg
remains
an
open,
open
conversation.
C
A
C
The
those
people
were
included
in
the
queries
and
we
got
no
sense.
I
would
say
yes,
we
have
consensus
on
that.
A
Cool
all
right,
so
let
the
let
the
record
reflect
all
right
all
right,
so
the
topics
are
ergonomic
brand
checks.
Same
key,
reified
name
are
records
and
tuples
objects
and
guards
daniel.
Is
there
anything
among
those
that
you
would
like
to
front
load
today.
A
Okay,
do
we
have?
Is
anybody
prepared
to
talk
about
guards.
B
I
am,
though,
in
the
future
I
may
have
a
more
comprehensible
write-up.
I
don't
have
anything
really
written
up
right
now.
So,
okay.
C
That
and
I
can
speak
to
some
degree
about
the
the
historical
guards
and
trademarks
proposal,
but
it's
a
long
time
ago,
so
my
number
one
it
might
be
rusty
daniel
having
actually
looked
at
the
old
proposal
recently.
It
probably
has
a
better
memory
of
that
one
as
well.
C
Oh,
and
we
should
also,
we
should
also
try
to
get
waldemar
to
come
in
on
the
guard
discussion.
As
you
know,
he
and
I
were
the
original
champions
of
the
old
guards
and
trademarks
with
great
cards
and
trademarks.
A
Okay,
so
I
think
that
we
have
material
for
same
key
and
records
and
tuples
as
objects
as
a
as
an
aggregate
topic
ergonomic
brand
checks.
Do
we
have
material
that
we
could
talk
about
today?.
B
So
did
I
send
to
this
group
previously
the
private.name
gist,
because
that
was
sort
of
my
thought
on
where
we
could
go
with
ergonomic
brand
checks
that
or
something
fancier
with
guards?
I.
B
I
can
share
it
in
the
in
the
chat,
but
probably
it's
better
if
I
share
it
ahead
of
the
meeting,
so
people
can
review
it
beforehand.
Okay,.
B
A
Okay,
I'm
I'm
going
to
leave
a
hole
for
daniel
to
add
a
link
to
the
minutes.
A
So
we
have
some
homework
for
future
meeting
and
I'll.
We
can
put
it
on
a
subsequent
agenda
whenever
on
a
week,
daniel
you're
available.
So
we
can
talk
about
that.
The.
A
Let's
see
so
and
then
ergonomic
brand
checks,
private
name,
that
that
you
said
that
that's
related
to
reified
name.
B
B
However,
the
I
thought
that
the
requirements
for
this
group
would
require
that
the
name
be
less
powerful,
so
that's
sort
of
the
discussion
I
think,
and
for
that
ideally,
we
could
send
a
message
to
jordan
and
see
if
he
is
interested
in
joining
this
conversation
with
us.
A
Cool
all
right,
well
that
whittles
it
down
to
the
topic
of
our
records
and
tuples
objects
and
particular
the
semantics
of
same
key
versus
same
value.
Zero.
Does
we
have
we
have
some
some
faces.
We
don't
rarely
see
in
this
meeting.
Are
there
any
topics
that
folks
on
the
call
would
like
to
visit
today
that
were
not
yet
mentioned
on
for
our
agenda
or
in
a
future
meeting?
For
that
matter,
cool
all
right.
A
A
That
of
that
would
require
breaking
changes
on
both
if
if
any
of
them
are
entertainable,
but
since
I
didn't
finish,
a
presentation
slide
deck
for
that
today,
we'll
bring
that
up
later,
all
right
mark
daniel.
Let's,
let's
talk
about
records
and
records
and
tuples.
B
So
I'm
happy
that
we
have
the
the
co-champions
of
the
proposal
here,
rick
and
and
robin,
and
I'm
not
sure
if
nicolo
might
also
be
here
yeah.
So
we
should
start
by
recapping
the
the
conversation
from
the
previous
meeting.
So
there
were,
there
were
a
number
of
sort
of
pros
and
cons
that
we
talked
about
for
objects
versus
objects
versus
primitives.
The
thing
is
that
the
original
arguments
have
maybe
diminished
in
importance.
B
One
of
the
original
arguments
was
for
objects
was
sort
of
implementation
complexity,
though
nikola
has
found
that
it's
kind
of
a
wash
for
implementation
complexity.
B
Another
one
of
the
arguments
was
permitting
a
box
type
to
be
nested,
though,
in
earlier
conversations
in
this
group,
I
believe
we've
roughly
concluded
that
maybe
we
can
expect
that
membranes
will
do
a
sort
of
deep
search
of
the
record
or
tuple
to
find
specifically
on
the
paths
leading
to
a
box
as
long
as
there's
an
efficient
query
to
deeply
query
that,
because
you
would
have
to
do
the
same
thing
on
it
on
an
object
anyway,
if
you
have
a
membrane
over
it
because
of
the
proxy
integrity
constraints.
B
So
therefore,
box
with
this,
if
we
have
this
deep
query
to
check,
if
a
box
is
included
or
accessible
box,
may
be
acceptable
for
either
primitives
or
for
objects
either
one
of
those
choices
for
records
and
tuples,
then
we
had
some
kind
of
more
forward-looking
arguments,
one
being
that
if
we
want
something
like
temporal
or
decimal
to
be
based
on
the
data
model
of
records
and
tuples,
the
trace
of
primitive
versus
object,
the
big
effect
there
is
whether
it's
that
value
that
points
to
its
prototype
or
whether
it's
a
per
realm
registry
in
these
values
are
realm
independent.
C
C
If
we're
starting
with
the
design
point
which
I've
I've
come
to,
prefer
that
they're
objects
without
identity,
that
they're
shallowly
frozen
and
shallowly
without
identity,
but
they
can
simply
contain
a
normal
objects
without
entity
and
with
mutability,
then
there's
no
need
for
a
box
type,
they
can
just
contain
stuff
and
then,
with
regard
to
the
path
query,
I
think
a
adequate
way
to
do.
That
is
that
that
fits
with
our
previous
discussions
is
to
do
the
query
on
the
other
side.
C
So
to
speak,
which
is,
is
this
a
shallowly
identity?
Free
object,
actually
deeply
identity
free
and
if
it's
deeply
identity
free,
then
you
know
you
can
pass
it
through
without
having
to
do
further
walking.
So
that
way
you
can,
as
you
walk
a
mixed
tree,
you
can
filter
out
the
subtrees
that
you
can
pass
through
without
worry
and
only
proceed
to
do
the
membraning
and
re-wrapping
of
the
of
the
parts
of
the
mixed
tree
that
lead
to
something
impure.
B
Yeah,
I
completely
agree
about
the
second
point
about
the
first
point
about
the
use
of
the
box
constructor
explicitly.
I
want
to
posit
that
that's
orthogonal
to
the
primitive
versus
object,
identity
list,
object,
question.
The
reason
I
think
it's
orthogonal
is
because
that
query
function
that
you
just
explained,
the
the
the
one
where
you
check
whether
the
shallowly
identity
free
object
is
deeply
identity.
Free,
would
sort
of
work
just
as
well
to
detect
if
the.
If
the
primitive
you
know
sort
of
directly
contains
an
object.
B
On
the
other
hand,
I
think,
for
either
formulation
primitive
or
object,
there's
sort
of
qualitative
ergonomic
benefit
to
requiring
an
explicit
opt
out
of
the
default
deep
identitylessness
and
deep
immutability.
This
is
not
a
categorical
change
in
semantics,
but
sort
of
a
it's
a
more
subtle
one.
So
I
think
I
think
this
is
something
for
us
to
discuss
further,
but
that
it's
that
it's
disconnected
from
the
object
versus
primitive.
C
Okay,
well,
let's
so
so,
just
since,
since
the
the
perspective
I
have
on
at
the
moment,
is
the
object
one
within
that
world?
Can
you
explain
what
the
motivation
would
be
for
introducing
a
box.
D
D
I
can
take
it
though,
so
the
one
of
the
major
design
goals
of
recording
tuple
is
that
we
avoid
this
kind
of
I
guess
sharp
edge
that
we
find
with
like
traditional
user
land
and
mutable
data
structures.
Libraries
around
accidentally,
including
mutable
state.
So
if
you
imagine
a
world
in
which
record
and
tuple
are
identical
objects,
and
they
just
simply
allow
you
to
place
any
object
on
as
a
value
of
a
record
or
an
element
in
a
tuple,
you
lose
that.
D
So
our
idea
with
box
is
that
it
maintains
that
record
literals
themselves
and
records
by
construction
via
the
record.
Constructor
are
immutable
by
default
all
the
way
down,
and
then
you
have
to
opt
into
this
behavior,
like
the
the
the
eye
view,
the
fact
that
you
dereference
a
box
as
a
selling
point,
because
it
means
that
you
have
to
opt
into
that
fact,
and
you
can't
accidentally
like
follow
a
tree
that
is
secretly
immutable.
You
must
opt
into
the
fact
that
it
is
beautiful.
C
So
so
so
I
think
I
think
I
understood
that
good
so
and
the
the
the
box
that
you
guys
are
proposing,
unlike
the
symbol,
is
one
where
all
you
need
is
the
box
to
unwrap
the
box
and
therefore,
when
you
use
a
box,
you
actually
are
including
immutability
directly.
It's
just
so
so
the
motivation
is
just
to
be
explicit.
C
Is
that
correct?
Yes,
okay?
Yes,
so
let
me
give
you
the
the
case
that
that
I
find
motivating
that
becomes
at
least
awkward
and
depending
on
your
criteria
impossible.
C
If
it's,
let's
say
a
map,
the
the
the
map
would
compare
with
with
other
such
snapshot
of
maps
using
same
key,
which
is
you
know
where
the
same
key
thing
comes
in.
But
the
key
thing
is
that
the
lookup
behavior
of
it
would
still
be
like
the
map
that
it
was
a
snapshot
of.
C
So
when
you
do
a
get
on
a
key
of
the
snapshot
of
map,
you
get
you
get
the
value.
That
was
the
value
of
the
original
map
at
the
time.
You
did
the
snapshot,
you
don't
get
a
box
around
the
value,
so
the
smooth
intro
operation
with
the
three
we
don't
reflection,
operations,
snapshot,
diverge
and
read
only
work
smoothly.
C
If,
once
you
get
beyond
the
shallow
layer,
you
just
have
the
same
objects
in
either
case.
This
applies
to
the
keys
as
well
is.
If
the
key
in
the
original
collection
was
an
identity
based
object,
then
the
snapshot
collection,
which
the
would
still
would
still
have
whatever
that
key,
was
at
the
time
that
the
snapshot
was
done.
C
E
Oh
good,
so
I
fixed
that.
I
I
think.
While
while
hearing
you
talk,
I
I
think
there
is
potentially
a
generalization
of
concept
here
that
we
can
try
to
do
and
for
us
it
seems
interesting
to
have
an
identity
based
object.
That
is
also
deep.
So
it's
the
the
shallowness
of
it
is
kind
of
an
issue
for
us.
But
that
being
said,
there
is
always
a
like.
There
should
be
a
way
to
also
store,
so
the
box
is,
is
that
kind
of
thing
right?
E
But
let's
say
that
we
also
have
the
concept
of
identity
object
applied
to
read-only
collections.
Read-Only
collections
could
also
behave
as
box
boundaries
the
same
way.
So
if
if
we
were
basically
to
say
that
an
identity,
less
deep
object
is
able
to
have
inside
shallow
identity-less
objects,
maybe
using
that
model
and
again
I'm
sorry
if
this
is
very
blurry.
My
explanation
right
now,
because
I
just
came
up,
could
basically
imagine
a
boundary
such
as
this.
C
So
I
sorry
I
don't
understand.
Let
me
ask
some
questions:
yeah.
Okay,
so
if
something
is
shallowly
identity-less,
let's
say
a
box
and
there,
and
by
shallow
we
mean
that
it
contains
objects
with
identity
or
identicality.
C
E
D
D
So
I
guess
what
we're
suggesting
is
that
the
that
there's
like
this
weird?
I
don't
want
to
say
invariant,
because
invariant
sounds
like
we've
come
to
consensus
on
it,
but
like
this
weird
idea
that
an
identity
of
this
object
can
only
become
you
can
only
craft
an
identityless
object
that
has
internal
mutable
state
like
or
points
to
mutable
state
via
a
box
that
you
would
also
need
boxes
for
read-only
collection.
C
Yeah
the
I
mean,
first
of
all,
let
me
let
me
endorse
using
the
term
and
variant
to
talk
about
hypotheticals.
C
You
know
to
but
yeah
the
let's,
let's
take
a
let's
take
a
more
direct
example
yeah,
since
the
proposal
does
have
tuples
and
since
tuples
are
sort
of
like
a
snapshotted
array,
except
for
the
fact
that
arrays
in
javascript
are
so
bizarre.
You
know
with
holes
and
all
sorts
of
crazy
things.
C
Let's
imagine
that
we
had
something
that
was
a
more
principled
mutable
ray
like
thing
so
that
maybe
fits
in
the
you
know.
Just
just
you
know,
spinning
fantasy
here
I
haven't
examined
this
in
any
detail,
but
something
that
fits
in
the
typed
array
hierarchy
in
the
sense
that
it's
no
holes
all
of
the
the
in
the
index.
Things
are
between
zero
and
one
and
length
minus
one.
They
all
have
the
same.
You
know
property
attributes,
etc.
C
Just
something
that's
well
behaved,
but
can
contain
objects
rather
than
just
containing
primitive
values.
The
it
would
be
attractive
to
be
able
to
extend
the
read-only
collection
methods.
The
three
methods
snapshot
read
only
and
diverge
to
convert
back
and
forth
between
tuples
and
some
kind
of
principled.
C
What's
a
principled
array
and
and
as
a
has
a
array
like
thing
that
has
identity,
and
that
is
mutable,
you
would
certainly
find
it
natural
to
store
objects
in
the
elements
directly
and
then,
if
you,
if
we
allow
a
snapshot
of
that
to
create
a
tuple
and
a
divergent
on
the
tuple
to
create
such
a
principled
array,
then
the
same
issue
comes
up.
The
reason
I
would
bring
that
so
now.
With
that
that
example
clear.
C
Let
me
I
can
go
back
to
what
I
was
thinking
about
with
regard
to
maps,
which
is,
I
was
thinking
that
maps
themselves.
C
This
is
this
is,
where
sort
of
the
whole
same
key
generalization
comes
in
that
maps
themselves,
that
a
map
snapshot
would
be
shallowly,
would
itself
be
shallowly,
identity,
free
and
shallowly
immutable
in
the
same
way
that
records
and
tuples
are
shallowly
identity,
free
and
shallowly
immutable
and
that
the
resolution
of
the
whole
you
know-
and
at
that
point,
when
you,
when
the
keys
can
be
arbitrary
objects,
the
we
have
to
find
another
solution
to
the
old.
C
Can
symbols
be
keys?
Can
symbols
be
property
names
of
records
because
clearly
arbitrary
objects
can
be
keys
and
maps,
so
so
any
and
any
solution
that
works
for
arbitrary
objects,
being
keys
and
maps
will
necessarily
work
for
symbols
being
property
names
of
records.
So
the
proposal
there
is
that
the.
C
That
we
generalize
same
value,
zero
into
same
key,
where,
for
all
the
existing
data
types
in
the
language,
same
value,
zero
and
same
key
always
do
exactly
the
same
thing
for
strings
and
symbols
same
value.
Zero
does
the
same
thing
as
same
so
for
strings
and
symbols.
It's
already
consistent
with
looking
up
of
property
names
on
both
objects
and
records,
and
then
and
then
the
new
thing
would
be
that
same
key
compares
records
order
independently.
C
So
it
is
an
equivalence
class
unlike
triple
equal,
triple
equals,
not
an
equivalent
class
because
of
the
behavior
on
that
like
same
value,
zero,
it's
an
equivalence
class,
that's
less
precise
than
object
is,
and
then
the
idea
would
be
that
for
all
of
the
existing
collections,
where
they
currently
compare
on
same
value,
zero.
C
But
what
that
means
is
that
when
you
store
two
records
when
you,
when
you
store
a
record
with
one
order
into
a
map,
and
then
you
look
up
a
record
with
a
different
order,
that's
the
same,
except
for
the
order,
difference
that
you
still
get
a
successful
map
line
and
then
finally,
the
whole
thing
folds
in
on
itself.
C
By
saying
that
a
snapshotted
map
is
itself
something
that
compares
in
a
order
independent
manner
with
regard
to
other
snapshotted
maps
using
same
key.
So
you
can
use
a
snapshot
of
map
as
a
key
in
a
map.
D
Gotcha,
okay,
so
the
same
key
stuff
makes
sense
that
tracks
with
my
understanding
of
it
so
far,
and
the
thing
that
you
highlighted
the
the
first
point.
D
First
part
of
your
point
is
the
part
that
I
was
missing,
that
when
you
want
to
convert
between
some
kind
of
like
read-only
or
sorry
like
mutable
map
in
your
read-only
collections
proposal
to
an
identity-less
version
that
that
obviously
is
incompatible
with
some
kind
of
explicit
box
requirement
because
then,
like
they
don't
come
out
as
they
come
out
as
bot
like,
if
you're
going
to,
for
example,
suggest
that
the
boxes
get
implicitly
wrapped
or
the
keys
and
values
get
implicitly
wrapped
into
boxes.
That's
a
problem.
B
Yeah
because,
well
you
know,
the
idea
that
I
proposed
in
the
gist
was
that
the
box
be
required
sort
of
on
the
way
in
and
then
it
would
get
unwrapped
afterwards.
So
it
still
would
work
to
have
the
sort
of
snapshot
return,
something
where
you
you
don't
have
to
do
draft.
But
when
you
create
a
literal
or
when
you
use
the
map
method,
you
would
still
have
to
create
a
box.
Something
like
that.
C
Okay,
I
understood
the
literal.
What
which
map
method
did
you
mean.
B
E
Yeah,
I
okay,
can
we
just
go
back
to
your
proposition
mark
and,
if
I
understand
well,
I'm
not
sure
so,
can
I
try
saying
it
with
my
own
words
and
and
see
if,
if
we
agree,
do
we
actually
in
that
model,
have
records
in
tuple
be
actually
shallow
identity,
less
subjects
and
in
which
case
I'd
like
to
understand
what
kind
of
equality
we
would
deal
with
in
that
in
that
model?
Okay,.
C
So
so,
basically
there's
two
equality
operations
that
we
would
still
support.
C
We
would
still
support
object.is,
which
has
the
same
invariant
that
it
has
now,
which
is
two
things,
our
object
that
is
equivalent
if
they're
observably,
equivalent
in
all
ways,
there's
no
observable
difference,
so
two
records
that
had
the
that
that
would
compare
the
same
with
same
key
but
which
would
enumerate
their
their
properties
in
different
orders
would
not
be
object.
That
is
the
the
reason
why
this
doesn't
create.
The
problem
that
we
are
originally
worried
about
is
that
none
of
the
existing
collections
do
a
look
up
according
to
object.
C
There's
there's
a
further
ergonomic
issue
which
I'll
just
punt
on,
because
it's
not
something
I
have
a
strong
opinion
about,
but
what
we
associate
with
triple
equals
triple
equal
is
not
an
equivalence
class.
We
have
triple
equal
for
the
cases
in
which
it
is
an
equivalence
class
agrees
with
same
value,
zero.
C
So
probably
the
right
generalization
of
triple
equal
is
that,
except
for
direct
man.
Comparison,
it's
otherwise
just
an
alias
for
same
key.
So
basically
it
says
if
both
my
operands
are
non,
then
I
do
the
triple
equal
thing
of
saying.
No,
and
otherwise
I
just
do
the
same
key
thing.
C
D
C
So
I
hadn't
thought
about
it
before
for,
for
the
literal
case,
like
I
see
the
explicitness
disadvantage
and,
and
in
the
literal
case
it's
really
in
some
sense
justice.
Syntactic
thing
the,
as
I
understand
the
unwrapping
on
the
way
in
the
collection
being
made
still
has
no
boxes
in
the
collection,
so
in
the
literal
cases,
makes
perfect
sense
to
me.
C
In
the
computed
cases,
sorry,
it
makes
perfect
sense
to
me.
I
still
don't
know
whether
it's
attractive,
but
it's
it
has
little
semantic
effect,
because
it's
just
a
syntactic
thing
for
the
api
cases.
I
just
don't
have
my
head
wrapped
around
them.
C
C
Okay-
and
I
see
robin
shaking
his
head
as
well-
I
know
daniel
has
so
in
any
case
in
e,
which
is
where
a
lot
of
my
intuitions
about
this
come
from.
C
We
didn't
have
anything
like
a
need
to
box
to
nest
these
things
in
each
other,
but
the
literal
syntax,
the
straightforward
literal
syntax,
where
in
javascript
we
would
just
write
square
brackets
or
curly
brackets
the
corresponding
straightforward
literal
syntax
in
e
made
what
we're
not
what
we're
calling
here
records
and
tuples
and
also
made
identity,
free,
shallowly,
identity,
free
maps.
C
So
the
direct
liberal
syntax
only
made
the
shallow
identity
free
things.
So,
therefore,
there
was
no
nested
literals
that
would
escape
back
to
mutability.
C
A
B
Kind
of
in
committee
that
we
don't
want
to
go
with
this
differentiating
variables
from
nested
literals,
with
the
concern
that
valdemar
raised
where
basically
he
said
this
thing
in
particular,
you
shouldn't
do.
C
It
I
I
agree,
I'm
mentioning
that
not
because
it
is
a
conclusive
argument
for
anything
in
particular,
but
just
sort
of
as
background
on
intuitions
from
a
different
language.
C
C
So
I
don't
know
the
in
the
in
the
literal
case,
having
a
syntactic
escape
to
get
back
to
mutability
is
something
that
I
I
think
is
plausible
and
I
think
not
doing.
That
is
also.
I
don't
feel
convinced
one
way
or
the
other.
D
Yeah,
I'm
a
little
bit
squeamish
by
the
idea
of
some
kind
of
syntactic
escape
only
because
well,
I
guess
not
just
only
especially
considering
the
way
people
will,
map
over
to
bulls
map
over
object
records
and
the
whole
point
of
making
this
like
escape
explicit
is
to
make
it
unambiguous
in
all
cases.
D
E
One
of
the
motivations
behind,
like
being
explicit,
being
having
like
to
do
something
to
the
reference
or
to
even
put
immutable
objects
in
the
in
the
records
interval
structure,
is
by
discussions
that
we've
been
having
with
other
engineers,
colleagues
that
actually
have
been
using
libraries
such
as
immutable.js
and
ending
up
with
something
that
is
mutable
in
their
hands
and
have
someone
else.
E
E
We
would
like
to
have
this
property
somehow
at
some
point
yeah
I
mean
so.
D
I
I
guess
my
I
started
me
to
cut
you
off
the
very
end.
Our
timing
didn't
work.
The
I
guess
the
way
I'm
thinking
about
this
is
that
it's
like
where
these
two
different
categories
of
features
need
two
different
things
right,
so
I
don't
think
it
would
be
unreal.
I
need
to
think
about
it
a
lot
more,
but
I
don't
think
it
would
be
unreasonable
to
state
that
the
invariant
that
that
mutable
objects
first
be
mapped
into
a
boxed
or
identity.
D
Full
objects
are
put
into
a
box
before
reaching
an
identity-less
object
must
exist
and
that
it
isn't
simply
a
special
case
for
record
and
tuple
in
general
that,
like
we,
that
this
also
tracks
with
like
temporal
and
temporals
need
for
like
internal
slots
for
their
calendars.
Those
are
immutable
I
assume,
but
they
would.
If
they
were
identityless
objects,
you
would
need
to
store
them,
but
you
don't
want
to
like
have
to
deal
with
boxes
around
that
edge.
D
B
B
B
Then
I
feel
like
for
things
that
are
not
records
and
tuples.
This
might
not
break
integrity
properties
because
the
integrity
is
sort
of
conceived
of
as
over
the
domain,
where
the
domain
of
a
record
and
temple
would
be
all
property
keys
in
the
domain
or
all
string,
property
keys
and
the
domain
of
say.
Temporal
object
would
really
be
more
about
its
internal
slots
because
it
has
no
own
properties,
and
if
we
made
it
identities
then
presumably
it
would
be
frozen.
That
way.
F
So,
just
to
clarify
the
majority
of
the
concern
was
about
those
domains
as
you're
calling
them
and
what
is
actually
enforced.
I
don't
think
we
have
any
way
to
clearly
state
what
integrity
is
for
other
kinds
of
types,
but
for
records
and
tuples.
We
are
actually
just
trying
to
preserve
those
integrity,
domains
we're
not
so
concerned
about
other
things.
F
For,
let's
say
temporal
was
an
identity-less
object.
Somehow
for
a
thought
experiment.
It
seems
to
me
at
least
personally
that
it
would
be
the
job
of
the
temporal
type
to
create
its
own
sort
of
integrity
domain.
E
D
B
C
So
so
something
that's
very
nice
about
this
place
to
draw
the
line
is
that
only
records
and
tuples
have
a
literal,
syntax
anyway,
snapshotted
maps
snapshotted
sets
anything
else
that
you
like
that
that
we
create,
since
it's
since
there's
no
corresponding
literal
syntax
for
the
mutable
form
in
the
language
right
now.
There
would
also
be
no
literal
form
for
the
identity
free
version.
D
Okay,
yeah.
I
think
I
need
to
give
this
a
little
bit
more
thought,
but
I
think
what
we
should
do
in
response
to
this.
I
think
there's
a
really
productive
path
for
this.
It
seems
to
resolve
some
concerns.
I
think
we
should.
We
can
do
a
write-up
of
this
in
more
detail
and
kind
of
see
if
it
plays
out
the
way
we
think
it
will.
While
we
do
that
and
then
come
send
it
around
see
and
get
some
more
detailed
thoughts.
Does
that
sound
right
to
you,
dan.
B
Yes,
I
guess
we
have
two
different
things
to
consider
writing
up
one.
Is
this:
the
evolution
of
the
identity
list,
object
idea,
and
the
other
thing
is
the
the
idea
about
comparing
keys,
which
could
help
us
take
into
account
deeply
immutable
maps
being
compared
in
an
order
free
way
by
by
the
triple
equals
comparison.
B
D
I'm
so
I
I'm,
I
don't
have
a
strong
opinion
on
whether
we
define
equality
between
these
against
objects,
the
same
key
versus
like
some
more
strict
guarantee
of
like
it's,
never
observable
whether
the
keys
are
in
a
certain
order
or
something,
but
I
don't
actually
know
what
the
background
is
on.
Why
saying,
he
would
be
chosen
over
something
like
the
keys
are
sorted
on
the
way
in,
like
the
original
proposal.
D
C
C
So
so
the
so
the
the
the
problem
we
ran
into
before
we
started
thinking
about
shallow
shallowly,
identity,
free
maps
or
snapshot
of
maps.
Is
that
what
do
you
do
about
unregistered
symbols?
Unregistered
symbols
can't
be
sorted
and
we
were
taking
a
hard
line
of
prohibiting
them.
I
was,
I
was
one
of
the
advocates
of
that
hard
line,
but
this
less
precise
equivalence
class,
I
think,
makes
that
issue
go
away
and
accommodates
arbitrary
objects,
as
keys,
which
is
necessary
for
the
shadow
map.
C
C
Tamping
down
the
explosion
of
concepts,
but
having
a
triple
equal,
be
basically
as
either
operand
and
nan
do
the
triple
equal
thing.
Otherwise
do
the
same
key
thing
is,
I
think
the
least
unpleasant
way
to
view
the
triple
equal
and
I
have
no
opinion
at
all
on
double
equal.
I
can't
even
think
about
double
equal
about
my
brain.
A
A
member
of
this
conversation
to
volunteer
to
write
a
resolution
down
in
our
minutes
that
captures
what
we've,
what
we've
discovered
from
this
conversation,
whomever
has
the
the
best
concrete
vision
of
it,
and
we
can
review
it
next
week
to
make
sure
that
we're
on
the
same
page.
D
Yeah,
I
don't
know
if
I
have
the
best
vision,
but
I
do
have
free
time.
So
that's
good
enough
right.
That's.
D
Thank
you,
okay,
so
this
makes
sense.
I
I
I
didn't
consider,
obviously
that
maps
need
that
kind
of
order.
So
he
doesn't.
I
guess
this
is
a
devil's,
not
it's
not
quite
a
devil's
advocate
because
nobody's
advocating
against
me,
but
this
is
a
thought
of.
D
If
we,
I
guess,
the
option
exists
to
us
if
we
think
that
the
original,
like
quality
of
the
integrity
of
like
the
keys
and
so
their
sorted
order
of
record
people,
was
valuable,
we
could
either
sort
them
anyway
in
the
same
way
that
we
would
unbox
things
implicitly
anyway
in
record
tuple,
and
in
that
like
take
an
opinion
on
that
route,
or
we
could
do
something
more
explicit.
D
This
would
also,
if
we
didn't
do
that,
the
other
option.
It
also
enables
us
to
use
record
or
symbols
as
keys
and
records,
because
they
would
no
longer
be
like
we
would
no
longer
have
to
sort
them
I'll
I'll
include
both
of
those
considerations
in
the
eventual
write-up
we
do
on
this.
I
don't
really
have
a
strong
opinion
either
way.
The
status
quo.
C
C
D
Right,
like
one
precludes
the
other,
if
we
went
with
the
same
key
solution
for
recommend
tuple
or
if
we
didn't
go
with
that,
then
we
can't
have
a
simple
keys,
yeah
I'll
I'll,
try
to
make
that
clear.
Yeah.
A
A
For,
for
example,
non-equivalent
symbols
that
have
the
same
description.
A
C
Right
for
for
shallow
maps,
for
you
know,
shallowly
immutable
maps.
What
I
think
is
natural
there
is
to
preserve
the
enumeration
order
of
the
map
being
special.