►
From YouTube: SES Meeting: Typeof Record and Tuple
Description
Wherein we discuss whether typeof should produce "object" or ("record" or "tuple") and the design tensions of supporting Boxes.
A
Yeah,
likewise,
I'm
using
my
new
knowledge
this
week.
Thank
you
for
clarifying
the
let's
see
on
the
agenda.
Nicolo
put
the
continued
conversation
on.
I
presume
nicola,
put
the
conversation
on
records
and
tuples
on
our
agenda.
Let's,
let's
start,
if
there's
anything
to
be
said
about
reflecting
on
tg1
and
tg3
on
the
record.
This
is
a
good
time.
C
Okay,
so
I
don't
know
if
everyone
saw
that
document
or
not,
but
my
motivation
for
writing.
It
was
that
I
missed
a
few
ses
meetings,
so
I
watched
them
and
I
figured
out
that
it
was
better
to
write
everything
down
to
make
sure
that
everyone
was
like
that.
We
were
not
talking
past
each
other
that
everyone
was
on
the
same
page.
C
So
I
tried
writing
down
like
different
conclusions.
We
had
and
the
two
biggest
open
questions
which
are
the
like:
should
records
and
tables
be
objects
or
primitives,
or
something
in
between,
I
don't
know,
and
how
to
make
them
like
how
they
should
interact
with
the
new,
like
with
their
arms
proposal.
C
Oh
okay,
so
I
think
I
brought
like
for
the
object
versus
primitives
question.
I
think
I've
wrote
all
the
different
options
that
we
ever
talked
about
and
so
like
one
was
to
make
them
primitives.
However,
these
have
like
this
has
problems
with
membranes,
because
I
mean
well
with
existing
membranes
that
wouldn't
be
able
to
to
like
to
catch
the
immutable
state
inside
of
boxes
until
they
they're
updated
to
actually
work
with
records,
tuples
and
box.
C
One
other
option
was
to
make
them
have
a
type
of
object,
and
this
has
problems,
because
currently
every
object
can
be
put
in
a
week
key,
while
some
or
many
records
and
tuples
would
not
be
garbage
collectible,
and
so
we
would
have
to
decide
like
which
is
less
bad
between
like
breaking
the
the
invariant
that
things
with
that
type
of
type
of
of
object
can
be
put
in
with
with
my
keys
or
to
relax
the
restriction
that
we
do
not
want
things
that
can
never
be
garbage
collected
as
a
weak
map.
Key
and
technically.
C
C
Yeah-
and
I
also
listed
like
a
few
invariants
of
what
objects
currently
are
and
how
they
differ
from
primitives
and
easily.
We
need
to
have
an
answer
like
for
each
invariant
like
for
each
of
those
environments
like
what
we
are
willing
to
break
or
to
change,
and
the
the
main
chart
characteristics
of
objects.
Are
that
triple
equal
and
object?
That
is,
is
the
same.
C
While
with
this
proposal,
it
would
like,
if
we
made
them,
have
a
type
of
object.
They
would
not
be
the
same
because
of
how
like
negative,
zero
works
in
records
and
tuples
and
then
also
well
with
the
also.
There
is
the
prototype
thing
that
objects
get
their
prototype
where
they
are
like
defined
and
not
where
the
prototype
is
used
and
by
the
way,
it's
possible
in
sloppy
mode,
using
function.color
to
create
something
like
a
lexically
defined
prototype
for
objects.
C
Yes,
so
well,
you
all
know
that
when
you
do
object,
dot
get
protected
off
of
an
object.
You
get
the
prototype
in
the
realm
where
the
object
was
created
thanks
and
if
you
do
object,
dot
get
prototype
of
of
a
primitive.
You
get
the
prototype
in
the
realm
where
we
are
calling
that
prototype
of
where,
in
the.
B
C
B
B
C
C
C
D
C
D
C
And
the
other
question,
where
is
how
to
handle
boxes
across
callable
boundary
on
realms
because,
like
one
option,
would
be
to
eagerly
traverse
the
the
record
and
to
throw
if
any
ob
if
any
box
contains
an
object
or
another
option
would
be
to
throw
when
trying
to
draft
a
box
to
unbox.
Sorry
to
unbox
a
box
like
in
the
in
the
realm
that
received
the
record
and
yeah
and
also
like
the
same
question,
is
what
to
do
about
functions.
A
So
I
don't
have
much
to
contribute,
but
my
I
I
unders
my
understanding
about
primitives
my
intuition
about
them,
regardless
of
the
specification,
is
that
they
are
effectively
realm
less.
They
are
not
affiliated
with
a
realm
so
that,
if
you
were
to
do
property
access
on
one
of
these
primitives,
what
you're
getting
is
not
a
property
of
the
of
the
intrinsic
but
a
property
from
the
execution
context.
A
In
the
case
of
number,
the
number
prototype
right
or
in
sloppy
mode,
a
box
a
box
around
the
intrinsic
and
with
a
with
records
and
tuples.
I
think
that
that
has
that
it's
desirable
right,
because
you
don't
have
to
do
any
locking
around
the
access
of
anything
within
a
record
or
tuple
unless
it
subsumes
a
box.
A
So
sorry,
I
didn't
understand
walking
like
if
you
were,
if
you
were,
if
you
needed
to
read
a
property,
if
there's,
if
there
is
a
realm
that
is
shared
by
threads
with
different
event,
loops
a
a
record,
a
primitive
can
be
shared
between
those
two
contexts
without
without
any
need
to
to
take
a
read
lock,
because
there's
no
possibility
of
writing.
Apart
from
garbage
collection,.
E
B
A
No,
the
different.
My
intention
is
that
my
intention
to
is
to
express
that
the
nice
thing
about
primitives
is
that
they
are
realm
lists.
They
don't
they.
They
don't
necessarily
have
an
associated
realm,
which
means
that
they
can
be
commuted
between
realms
and
different
threads
freely.
Apart
from
the
semantics
of
garbage
collection,
yeah.
E
D
A
D
E
A
D
A
D
A
B
Okay,
I
think
I
think
a
fundamental
invariant
of
what
can
be
shared
between
threads
is
that
all
there
has
to
be
complete.
Disjointness
of
reachable
of
transitively,
reachable
mutable
state
and
therefore
a
a
box
containing
a
mutable
object
cannot
be
shared
between
threads
and
therefore,
a
record
and
tuple
containing
a
box
containing
a
mutable
object
cannot
be
shared
between
threads.
G
F
C
D
Yeah,
I
agree
that
they're
very
distinct,
the
thread
boundary
case
is
not
totally
theoretical
or
in
the
future,
we're
working
on
an
realm,
hg
or
actually
nikola
wrote
a
proposed
specification
for
how
realms
would
work
with
html
and
project.
Sorry
not
realms
how
how
records
of
tuples
would
work
with
html
in
particular
with
structured
clone
and
so
that
that
specification
is
written
to
permit
an
implementation
to
not
copy
when
sharing
between
threads,
but
there's
no
way
to
detect
it.
That's
the
that's
the
whole
thing
with
records
and
doubles.
There's
no
observable
identity.
D
Comparison
is
structural,
so
you
just
have
no
way
of
seeing.
The
only
question
is
what
happens
with
with
boxes.
One
possibility
would
be
that
they
could
be
opaque
handles
in
the
other
thread.
Another
possibility
is
that
they
could
have
the
structured
clone,
algorithm
or
curse
into
them.
I
guess
some
people
here,
don't
like
structured
clone.
A
E
A
D
A
D
I
I
agree
with
that,
and
that
was
the
question
that
I
just
raised
about
like
whether
with
when
moving
them,
you
could
project
everything
with
a
box.
You
could
make
the
box
into
an
opaque
handle
or
you
could
deeply
copy
that
and
make
it
into
a
totally
different
thing
but
yeah.
I
agree
that
there's
not
you
can't
just
make
that
mean
nothing,
but.
G
A
H
So
so
I
have,
I
have
okay,
so
things
may
fall
into
the
category
of
stupid
questions
that
might
be
illuminating
and
and
something
I've
been
having
a
little
bit
of
trouble
with
all
along,
and
I
think
the
the
issue
is
not
so
much.
What's
the
answer
to
my
question,
but
the
active
answering
question
might
be
insightful
which
is:
can
we
can
we
articulate
how
it
is
that
a
a
record
containing
a
box
is
in
in
any
important
way
different
from
just
an
immutable
object?
H
A
I
think
that
that
goes
over
that
that's
a
bit
circular,
because
we
have
often
discussed
in
this
meeting
what
those
are
for.
So
let
me
reiterate:
I
I
think
that
we're,
I
think
daniel
brought
boxes
to
the
conversation
specifically
because
of
the
motivating
use
case
of
oh
crap
membranes.
Was
it
membranes.
D
Yeah
they're,
making
motivating
use
cases
and
one
one-
that's
pretty
easy
to
understand-
is
bradley
you're
kind
of
subsuming
and
generalizing
bradley's
multiple
compound
keys
for
for
weak
maps.
This
will
make
a
generalization
of
that.
You
have
multiple
things
that
can
can
be
references
to
objects
which
are
you
know
in
one
structure.
That's
compared
by
value.
Another
example
which
I
don't
know
if
it
would
be
directly
useful
that
we've
that
we've
talked
about
is
like
vdom.
D
The
implicit
boundaries
that
you
know
object.freeze
leaves
you
with,
is
a
big
source
of
bugs
today
and
if
we
don't
have
box,
we
would
be
forced
to
use
a
side
table
based
approach
like
with
symbols
as
weak
map
keys
and
bradley
has
indicated
that
there's
both
a
risk
of
memory
leaks
if
you
use
maps
instead
of
weak
maps
and
there's
also
a
risk
of
you
know.
How
do
you
manage
all
these
side
tables
so.
H
D
H
E
H
It's
got
some
of
the
arcs
of
the
graph,
and
you
say
everything
within
this
boundary
is
immutable,
but
there
are
arcs
that
exit
through
the
boundary
and
the
boxes
are
those
are
those
exit
arcs
and
I
can
see
that
being
very,
very
handy,
but
there
is
a
notion
of
of
you
have
an
entry
and
some
number
of
possible
exits,
but
what
they
exit
to.
I
think,
there's
a
question
of
whether
is
what
they
exit
to
defined
within
the
boundary
or
is
it
defined
externally?
H
A
Yeah
so
so
let
me
propose,
let
me
propose
a
straw
man
for
an
implementation,
suppose
that
suppose
that
you
were
to
implement
records
and
tuples,
and
you
wanted
to
protect
the
invariant
that
they
could
be
trivially
shared
between
threads,
then
you
might
be
tempted
to
implement
boxes
as
a
pure
data
value.
That
is,
that
is,
that
does
not
vary
between
threads.
A
For
example,
let's
say:
32
bytes
of
random
numbers
like
a
uuid
and
then
in
the
realm
in
which
they
are
created.
That
box
would
have
they
that
the
realm
would
have
a
lookup
table
from
this
uuid
to
the
mutable
state.
That's
in
turn
that
exists
in
that
realm
and
then
in
the
other
realm
it
doesn't
there.
There
is
no
corresponding
value
in
that
lookup
table,
so
the
box
like
as
described
previously
one
possible
implementation,
is
that
the
box
refers
to
nothing
when
it's
transferred
to
another
realm
is:
is
that.
D
I
I
do
think
this
is
a
question
that
has
multiple
answers:
how
to
transfer
these
object
graphs,
and
so
I
think
you
know
we're
working
on
an
answer
for
html,
structured
clone
and
other
things
may
have
different
answers,
but
I
also
think
that
this
is
a
question
which
is
totally
orthogonal
to
the
agenda
item,
which
is
about
what
the
type
of
is.
I
think
the
type
of
does
not
affect
what
the
cloning
behavior
is
or
whether
box
should
exist.
E
B
G
F
There
is
a
question
of
authority
here
when,
when
you
have
the
site
table,
you
have
the
authority
to
do
the
lookup
here.
You
only
need
to
have
the
the
you
need
to
have
a
reference
to
the
box
or
to
the
the
frozen
or
to
the
immutable
record
tuple
to
be
able
to
have
the
authority
to
reach
that
immutable
state.
F
I
I
just
want
to
say
something
for
clarification,
maybe
for
chip
and
and
then
also
my
point
of
view,
so
the
box.
It
provides
an
exit
point
and-
and
I
think
one
reason
for
that
is
because
a
record
couple
cannot
have
a
direct
link
to
a
regular
object
or
function
or
anything
like
that.
There
is
no
way
to
really
associate.
F
Basically,
the
box
is
a
tag
for
that
and,
and
it
allows
to,
it
allows
to
put
a
hole
in
the
immutable
structure
copy
by
value
structure
to
something
else,
which
is
why
I've
come
around
and
I
believe
there
is
value
in
the
box
mechanism
purely
as
an
identification
here
at
this
path.
There
is
something
you
can
reach
out,
that
is,
that
is
usable,
but
the
structure
itself
doesn't
change,
or
else
you
do
need
to
have
an
ascending
of
what
the
structure
is
to
know
that
at
that
path.
F
F
E
D
Yeah,
no
one
has
proposed
an
api
to
say
to
indicate
where
they
are.
So,
if
you
have
any
ideas,
then
maybe
say
so
in
an
issue
or
something
I
think
the
current.
The
current
idea
is
that
we
have
this
predicate.
That
tells
you
does
this
thing
contain
it,
and
so
you
can
iterate
through
an
object
and
run
that
on
several
different
parts
of
it.
D
Well,
even
better
than
that,
we
you
can
already.
You
can
obviously
know
when
you're
crossing
the
boundary
by
checking
whether
something
is
a
box.
But
you
get
this
nice
thing
that
lets
you
not
traverse
the
sub
trees
that
are
all
sort
of
clean,
because
you
can
run
this
predicate
that
that
works
recursively
based
on
the
bottom
up
sort
of
precomputation,
of
whether
it
contains
one
of
those
things.
A
We
have
15
minutes
left
on
the
meeting
and
I
really
do
want
to
honor
daniel's
request
to
to
to
get
back
to
the
the
locus
of
the
question
the
so
so
let
let's
I
I
I
did.
I
I
find
it's
a
bit
my
strong
man
to
be
sufficient.
I
think,
to
understand
the
nature
of
the
problem
and
and
I'm
happy
to
move
on,
nicolo
go
ahead.
C
Yeah,
I
was
saying
that
I
think
that
it's
like
for
the
second
question:
it's
even
if
we
end
up
discussing
about
it
when
done
is
not
here,
it's
a
less
fundamental
question
that
what
do
we
type
off
so
it's
more
important
to
stick
to
the
type
of
question
now,
oh
yeah,
and
also
I
wanted
to
ask.
So
it
is
an
a
security
problem
to
have
something
which
is
not
type
of
object,
but
that
can
contain
objects
from
a
membrane
perspective.
C
I
do
not
fully
understand
how,
but
I
I
mean
I
trust,
people
who
know
more
about
this
than
me.
I
wanted
to
ask
if
this
is
a
security
problem,
because
you
could
like
actually
like
access
to
the
access
like
objects
of
ariane.
We
are
trying
to
attack
and
which
is
not
protected
anymore
by
the
membrane
because
of
record
and
apple
and
box,
or
if
it's,
if
it's
like
a
communication
channel
but
like
between
two
like
two
different
untrusted.
C
F
D
D
On
this
page,
are
those
really
bad
like
the
mismatch
between
triple
equals
and
object?
Dot
is
these
are
these
are
some
concerns
that
jordan
raised,
and
so
so
in
this
document,
nicolo
is
raising
the
the
contradictions
between
different
invariants.
The
different
parties
have
raised,
and
so,
given
the
arguments
that
matteo
and
and
bradley
made
for
boxes,
then
the
question
is:
how
do
we
work
through
these?
These
contradictory
invariants
or
goals.
E
F
D
This
is
just
about
whether
how
triple
equals
works
on
net,
which
does
not
rely
on
whether
it's
the
same
man
or
different
men,
and
what
we're
saying
is
that
a
tuple
containing
a
temple
of
men
does
triple
equal,
a
tuple
of
men.
It
doesn't
do
the
thing
where
nan
doesn't
triple
equal
noun.
The
way
that
it
works
for
scalars,
because
having
nan's
sort
of
black
hole,
records
and
tuples,
making
an
infinite
set
of
things
that
don't
triple
equals
themselves
would
be.
You
know
unfortunate,
that's
sort
of
what
we
decided.
D
There
just
seemed
to
be
a
camp
of
people
who
are
pushing
back
towards
the
idea
that
even
zero
and
negative
zero
would
be
not
triple
equals
when
nested
in
records
and
tuples,
because
if
objects
are
triple
equals,
then
there
then
object.
That
is
is
true
for
two
objects
today.
So
there's
an
argument
that
if
records
and
tuples
use
type
of
object,
then
they
can't
use
the
definition
of
equality
that
unifies
zero
or
negative
zero.
D
Similarly,
there's
yeah
there's
this
thing
about
objective
x,
there's
also
like,
should
they
be
allowed
as
as
weak
map
keys,
should
they
all
be
allowed?
We
were
talking
about
that
previously
and
bradley
gave
some
strong
arguments
that
I
agree
with
that
records
and
temples
that
don't
contain
boxes
containing
identities
should
not
be
allowed
as
weak
map
keys,
and
so
there's
the
argument.
Oh,
but
that's
also
not
acceptable
if
type
of
is
object.
So
how
should
we
resolve
these
contributions?
Nicolas
laid
out
the
different
arguments
very
clearly
here.
A
I
I
I
see
a
little
value
for
box
like
for
all
the
things
that
all
the
good
value
that
records
and
tuples
are
bringing
by
itself
without
the
box,
so
it
all
leads
to
the
the
matters
of
like
if
we
should
have
walks
or
not.
I
think,
with
the
light
of
the
recent
presentation
from
shu
of
the
shared
object
like
there
is.
The
property
structure
is
not
mutable,
just
the
values.
E
B
I
I
think
that
brings
just
new
light
of
what
what
I
would
want,
but
it
still
doesn't
resolve
all
the
problems
here.
I
think
what
we
have
with
records
and
tuples
are
good
and
the
problems
like
the
just
by
having
boxes
like
by
solving
this
problem
itself,
this
problem
itself.
I
think
this.
The
only
reason
like
this
problem
is
trying
to
be
resolved
is
because
we
have
box
the
problem
with
caliber
boundary.
Realms
is
because
we
have
blocks
like
I
honestly,
no
there's.
D
No
problem
with
callable
boundary
realms
that
relates
to
box.
We
have
a
simple
solution
for
that
I
mean
so
this
just
a
very
frequent
occurrence
in
gc39,
where
we
have
semantic
points
and
we
need
to
talk
through
them.
I
don't
think
the
fact
that
there's
something
that
we're
talking
through
means
that
it's
too
too
heavy
to
be
worth
it
I'd.
Rather
we
just
I.
Rather
we
focus
on
possible
solutions
to
to
problems.
I
I
don't
want
to
add
any
step
like
for
qualifying
primitive
values
like
records
and
tuples,
to
see
if
they
have
a
box
and
if
they
have
a
box
if
they
contain
something
that
is
not
a
primitive
value
that
cannot
be
shared.
I
don't
want
to
be.
I
don't.
I
would
love
to
not
add
any
step
in
the
shadow
realms
api
to
qualify.
What
I'm
transferring
like
other
than
what
we
already
have
today
like.
Is
it
callable
or
not?
I
think
that's
already
like
a
little
bit
on
the
edge.
I
I'm
like.
F
You're,
pushing
the
complexity
to
programs
than
that
want
to
reference
objects
from
from
their
record
like
that.
That
will
need
to
be
put
in
structures
that
are
containing
the
records
that
are
going
alongside
it
and
that
will
need
to
be
somehow
efficiently
implemented
or
efficiently
compatible,
with
whatever
membrane
will
live
on
on
top
of
shadow
rails.
F
We're
we're
here
if
it's
something
that's
part
of
the
language,
there's
an
opportunity
for
membrane
implementations
to
do
the
optimize,
the
the
right
thing
there
for
for
for
everyone,
without
having
every
program
having
to
re-implement
that
I
mean
it's
the
same
today.
It's
the
same
today,
you
can
create
equivalent
to
records
and
tuple
using
frozen
objects.
It's
just
really
hard
to
do
and
error-prone
it's
I
I
I
said
I've
come
around
and
I
feel
like
it's.
It's
solving
the
problem
halfway.
A
A
Live
the
string
record
or
people
in
the
presence
of
boxes,
that
would
be
a
security
violation
that
would
be
intractable
and
that
everyone
here
would
would
prepare
that
that
would
be
intractable
and
we
could
not
accept
that
from
a
security
point
of
view
and
therefore,
if
there
are
boxes
within
records
and
tuples,
we
must
accept
the
downsides
of
the
of
of
the
changes
in
semantics.
To
object
is
get
prototype
of,
etc.
D
E
A
F
A
B
B
B
D
B
D
There
there
were,
there
is
a
debate
within
the
semantics
of
box
about
whether
you
should
have
to
de-reference
it
from
the
same
realm
or
different
realm.
So
this
is
different
from
the
context
of
shadow
realms
where
you
have
callable
boundaries
that
would
prevent
it.
But
when
you
have
the
multiple
same
origin
iframe
case,
we
could
say
that
the
unboxed
method
only
works
if
it's
from
the
same
realm
where
the
box
was
created,
or
we
could
say
that
the
that
it's
from
the
or
we
could
say
that
it's
just
not
not
referenced
at
all.
D
D
B
B
D
D
Okay,
so
so
we
ended
up
going
with
the
latter
one
so
far.
Okay,
because
the
the
former
one
would
really
make
more
sense
in
the
case
of
if
we
went
with
callable
boundary
realms
where
we
did
allow
the
boxes
to
go
in.
You
know
we
had
a
bunch
of
discussion
about
this.
We
decided
no,
we
actually
just
want
to
reject
those
in
the
first
place,
and
I
think
we
had
good
reasoning
for
that.
B
D
So
you
know
the
the
controversy
about
callaway
boundary
realms
was
mostly
not
about
bucks.
Most
of
the
controversy
around
callable
boundary
realms
was
about
whether
we
want
to
make
callable
boundaries
at
all.
So
I
I
really
feel
like
the
problems
here
are
overblown.
I
think
we
have
two
good
solutions
on
the
table.
I
think
either
one
could
work
if
the
right
kinds
of
software
are
updated.
I
think
it's
kind
of
normal
to
have
new
things
added
to
the
language
over
time
that
work
differently
from
the
things
that
were
there
before.
D
D
I
mean
I'm
I'm
fine
with
sticking
here
towards
the
type
of
object
direction,
but
I
still
am
not
really
convinced
the
type
of
record
and
tuple
and
box
would
be
wouldn't
be
so
bad.
It
would
just
mean
that
codit
wants
to
really
soundly
traverse
through
data
structures,
we'll
have
to
add
those
those
cases
which
is
a
real
cost,
but
I'm
not
convinced
that
it's
totally
fatal,
but
if
we
want
to
make
the
trade
off
we're
going
with
object,
that
seems
like
a
reasonable
trade-off.
C
A
F
F
C
E
D
Okay,
so,
within
this
object
solution,
can
we
go
into
if
people
are
okay
with
staying
a
little
over?
Can
we
go
into
a
little
more
detail
on
how
bad
the
type
of
object
is?
Given
you
know
these
four
conditions
that
are
that
are
listed
about
you
know
not
all
of
them
being
weak
map
keys
about
the
triple
equals,
not
implying
object.
That
is
even
another
type
of
object
like
how
how
bad
are
those
mismatches
versus
current
behavior.
E
E
B
D
F
E
B
Well,
I
mean
you
could
certainly
build
a
membrane
that
was
non-transparent
in
that
regard,
but
the
default
practically
transparent
membrane
cannot
use
that
behavior.
Fortunately,
it
doesn't
have
to
use
that
behavior
as
we
discussed
you
can
read,
because
the
record
and
tuple
structure
up
to
the
exits
must
be
acyclic.
F
Yes,
that's
what
I'm
saying,
but
I'm
I'm
saying
we
shouldn't
automatically
disallow
proxy
targets
records
and
abolish
proxy
target.
We
should
allow
them.
We
just
need
to
acknowledge,
they
will
not
be
fully
transparent
and
we
will,
like
code,
will
be
able
to
realize
this
is
a
proxy
that
doesn't
and
it
doesn't
behave
entirely
as
a
recurring
temple.
It
just
behaves
as
a
proxy
to
a
frozen
object.
Since
then,
you
describe.
F
B
The
code
has
to
change
and
the
fact
that
it's
possible
to
do
so
is
good,
but,
on
the
other
hand,
there's
also
old
membranes
whose
code
did
not
change
and
for
those
we
wanted
to
fail
soft,
so
they
lose
the
level
of
transparency.
We
would
like
that
they
were
originally
built
to
have,
but
they
continue
to
be
working
membranes.
Is
that
matthew?
Am
I
getting
the
the
motivation
correct?
Okay,
so.