►
From YouTube: SES-mtg: Spec Invariants. CapTP and distributed memory
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
C
B
D
I
summarized
our
discussion
from
last
week
here
and
it
sort
of
sketched
out
a
shape
for
this
and
I
also
listed
the
abandoned
I
created
two
files
abandoned
invariance
and
known
invariance,
just
around
what
we
discussed
and
the
abandoned
invariance
I
added
the
one
that
mark
mentioned
and
I
didn't
catch
all
of
the
detail
there.
So
that's
something
that'll
need
to
be
clarified.
A
bit.
I
just
gave
everything
a
little
bit
of
shape
and
in
known
invariance
I.
D
A
D
D
It'll
be
fine
okay,
so
here
we
have
a
been
an
invariance
and
I
have
a
template.
I
use
this
consistently
for
all
of
them
and
we
can
modify
this
template.
This
is
just
the
thing
that
I
came
up
with
alone,
it'll
change
and
the
first
one
that
we
have
to
test
this
out
is
the
type
of
behavior
between
loose
equality
and
strict
equality.
D
The
description
I've
written
down
is
if
the
result
of
type
of
a
and
B
were
the
same.
The
result
of
loose
equality
and
strict
equality
should
be
the
same.
This
was
relaxed
with
value
types.
This
description
I
got
from
the
notes,
but
I
don't
know
if
it
was
accurately
recorded.
Does
that
sound
right,
I
would.
B
Refine
it
a
little
bit
the
when
you
say
it
was
relaxed
with
value
types.
We
don't
have
value
types,
yet
the
value
types
is
anticipated
and
the
there's
also
this
other
operator
puzzle
that
was
done
that
also
from
dan
dan
/
Ehrenburg
that
he
did
in
response
to
despairing
about
whether
we
could
get
many
types
both
of
those
relax.
B
D
B
E
E
B
I
would
say
that
that
is
an
example
of
an
abandoned
invariant.
You
know
it
was
an
invariant
in
the
sense
that
it
was
a
regularity
that
the
spec
obeyed
the
fact
that
the
argued
about
it
meant
that
something
that
we
were
aware
of
it
and
that
some
people
were
in
favor
of
it.
So
it
was
an
invariant
that
we
that
the
that
was
a
proper,
the
spec
that
we
decided
to
abandon.
E
F
B
F
B
Think,
that's
that
that's
mischaracterizing
the
intention
the
what
what
what
at
least
I
mean
by
an
invariant
when
I
raised
the
whole
topic.
Our
regularities
that
were
true
that
are
there
are
true,
even
if
they
weren't
written
down
many
much
of
what
we're
trying
to
do
now
is
I
mean
part
of
the
point
of
the
current
exercise
is
to
get
some
of
these
things
written
down,
but
many
of
these
things
have
never
been
written
down
like
the
thing
about
double
equals
and
triple
equals.
B
They
don't
remember
ever
seeing
that
written
down
better,
but
certainly
an
important
part
of
the
es5
discussions.
It's
probably
the
meeting
notes
where
the
only
would
be
the
only
place
they
would
have
ever
appeared.
The
thing
about
string
concatenation
is
I
would
still
say,
abandoned
invariants
in
the
title
of
there,
because
an
invariant
it
wasn't
a
proposed
invariant,
because
invariant
is.
It
means
that
it
was
actually
true
across
the
spec
which
it
was.
D
So
I'm
wondering
I
was
also
thinking
of
invariants
as
something
people
have
defended,
but
I
think
it's
I
think
both
are
true.
I
wonder
if
there
should
be
a
way
to
because
there
are
many
things
that
are
true
about
the
spec
and
we
may
not
be
able
to
write
them
all
down.
We
might
not
be
aware
of
all
of
them,
but
there
are
certain
things
that
have
been
defended
about
the
spec
right.
B
D
D
B
G
This
this
goes
along
with
this
sort
of
the
this
sort
of
common
law.
Well,
you
know
this.
Everybody
knows
X
when
it's
not
actually
in
this
back
and
some
of
these
invariants
are
well.
Everybody
knows
that
this
is
an
invariant
and
some
of
them
are
well
yeah.
The
spec
says
this,
but
nobody
actually
implements
it
that
way,
and
once
again,
there's
an
effort
to
bring
this
back
into
compliance
with
reality
through
editing,
I'm,
not
sure
that
belongs
here,
but
it
strikes
me
that
these
things
are
potentially
related.
D
We
do
have
an
issue
with
having
informal
knowledge
spread
across
specific
individuals
in
committee.
That's
definitely
true,
because
I
think
that,
for
example,
this
thing
of
everyone
knows
it's
everyone
who
can
speak
about
that.
Subject
knows
and
I
think
that's
why
it's
so
powerful
to
write
this
stuff
down.
We
should
get
as
much
of
this
written
down
as
possible,
but
that's
definitely
a
secondary
task
that
we
need
to
do.
D
B
D
B
A
A
B
B
I'd
say
the
real
issue
is
that
it
used
to
be
the
case
that
everything
was
generative,
because
it's,
the
the
you
know,
the
the
the
syntax
is
means
by
which
the
invariant
was
broken.
But
the
important
invariant
was
that
the
things
being
created
anything
that
you
can
create.
You
can
mult
instantiate
it
because
you
can,
because
that
would
be
the
effect
again
in
the
function.
D
D
E
D
E
One
that
people
find
surprising
is
the
instance
of
operator
change
when
we
introduced
the
symbol
for
it.
They
they
found.
That
instance
of
was
a
reliable
way
to
do
checking
and
we
altered
that.
Basically,
every
symbol
we
introduced
has
some
level
of
breakage
that
we
observably
see
where
libraries
rely
on
behaviors
and
we
by
allowing
them
to
be
altered,
break
those
okay.
D
D
B
B
Why
was
it
useful?
Because
the
to
string
thing,
I'm
sure
initially
happened
by
accident?
It
happened
without
any
simply
without
anybody
having
thought
about
its
utility
as
a
branding
mechanism.
Once
it
existed,
people
started
using
it
as
a
brand
track
and
and
their
ability
to
use
it
as
a
brand
track
was
because
it
was
an
invariant,
even
though
it
was
an
invariant
that
originally
arose
accidentally
mm-hmm.
E
D
B
C
B
B
B
Yeah,
that's
right,
define
get
her
to
find
setter.
Look
up,
get
her
what's
up
center.
There
were
these
dunder
properties
that
are
still
de
facto
present
on
object
prototype.
So
yes,
five.
We
took
the
rule
that
anything
that
was
true
in
three
out
of
the
four
browsers
was
a
strong
candidate
for
codification
in
DES,
five
and.
B
D
A
A
A
B
So
I'm
going
to
introduce
I'm
going
to
coin
a
term
which
is
an
exotic
internal
slot
and
what
I?
So
we
already
have
in
the
spec,
the
terminology
of
exotic
versus
normal
objects
for
the
normal
objects.
There's
a
set
of
slots
defined
as
the
slot
has
the
the
slots
that
normal
objects
have
any
slot.
That
is
not
in
that
set
I'm
going
to
go
ahead
and
define
as
an
exotic
slot.
I
need
terminology
fork.
B
D
B
A
B
B
B
B
So
committee
came
up
with
this
mirror
membrane
idea
that
they've
been
doing
work
on
in
Salesforce.
It's
very
clever.
It's
it's
different
than
the
normal
membrane,
and
the
near
membrane
is
trying
to
make
objects
that
are
on
the
other
side
of
the
membrane
seem
to
just
be
regular
objects
within
this
realm.
So
is
a
realm
bound.
The
membrane
boundaries
in
Puryear
membrane,
the
membrane
boundary,
is
not
perceived
to
be
like
a
round
boundary
and
as
and
that's
a
different
form
of
transparency
than
the
normal
membrane
transparency
that
I've
been
defending
over
the
years.
B
B
B
The
target
might
very
well
be
the
object
that
has
the
internal
slot,
but
the
proxy
mechanism
purposely
does
not
punch
through
to
the
target,
and
the
result
is
that
you've
that
the
date
object,
for
example,
whatever
object
it
is,
he
carries
the
internals
while
fails
to
act
like
a
near
object.
The
fact
that
you're
accessing
it
through
a
proxy
breaks
the
illusion-
and
then
you
can.
B
D
D
B
In
the
case
of
newer
membranes,
they
break
crap
practical
transparency,
but
this
is
true
for
just
introducing
exotic
internal
slots
in
general,
then
I'm
going
to
take
the
second
step,
which
is
why
the
internal
swap
vert
holding
objects
is
a
different
category
of
danger
than
an
internal
slot
holding
data,
which
is
if
the
internal
slot
holds
data.
Then
this
weird
monkey
patching
you
need
for
near
membrane,
transparency.
B
If
it,
you
know,
if,
if
this
new
mechanism
effectively
punches
through
and
accesses
it
from
the
target,
well,
then
you've
successfully
access
the
data
from
the
other
side
of
the
membrane,
which
is
not
at
all
dangerous.
It's
actually,
the
transparency
that
you
were
crying
for
and
data
is
supposed
to
get
it
go
through
membranes
without
modification.
B
If
the
internal
holds
an
object,
then
you
have
to
be
than
any
kind
of
punching.
Three
mechanism
has
to
be
in
a
much
deeper
way
in
bed
with
membrane
mechanism,
because
the
reference
as
provided
on
the
other
side
of
the
membrane
must
itself
be
membrane.
You
can't
just
convey
the
capability
itself,
because
then
you
break
membrane
isolation.
B
And
the
reason
why
this
isn't
fatal
is
that
the
you
know
you
already
have
to
do
this
complex
intervention
to
create
near
membranes.
The
complex
intervention
can
be
made
more
complex
in
this
way,
but
it's
a
cost
and
it's
a
cost
not
just
in
complexity.
It's
a
cost
in
potentially
breaking
security.
If
you
make
a
mistake
at
something,
that's
already
complicated.
D
D
Okay,
and
so
this
second
half
this-
is
the
trickier
bit
of
this
actually
before
we
get
into
that.
I
want
to
get
a
better
definition
for
near
membrane
if
we
have
a
definition
written
down
somewhere
for
near
membrane,
I
can
pull
it
out
of
there.
If
you
give
me
a
link
or
we
can
try
to
knock
it
out
here,.
A
B
B
Okay,
now
there's
something
that's
also
about
exotic
internal
sloths,
that's
actually
more
important
than
the
thing
about
avoiding
you
know
about
that.
The
more
important
than
the
data
versus
object
distinction
mm-hmm
and
this,
but
this
one
is
a
soft
invariant,
because
we
have
a
few
violations
and
that
it
soft
invariant
is
that
methods
or
accessors
that
access
exotic
internal
swats
only
access
them
on
there.
This
argument.
B
Mm-Hm
and
the
reason
why
this
is
so
important,
this
is
the
reason
why
membranes
can
be
practically
transparent,
not
near
membranes.
Just
normal
membranes
can
be
practically
transparent
where
what
I
mean
by
transparent
is,
if
you
put
them
between
realms
it
acts
as
if
it
acts
just
like
realm
boundary,
as
if
there's
no
membrane
between
the
realms.
So
you
still
have
all
the
Samantha
costs
of
a
round
boundary
which
turned
out
to
be
really
tricky
and
hazardous
on
their
own.
B
Date
instances
have
an
exotic
internal
slot
that
actually
holds
the
date
and
time
value
and
all
of
the
get
and
set
methods
on
date
thought
prototype
all
of
them
access
or
modify
that
internal
slot,
but
they
only
do
it
on
there.
This
argument,
the
result,
is
that
if
I'm,
let's
say
on
the
yellow
side
of
the
membrane
and
I,
have
a
yellow
proxy
for
a
blue
date
and
on
my
yellow
proxy
I
do
date.
B
This
invariant,
the
the
the
thing
that's
not
transparent,
even
with
this
invariant
there,
and
which
is
the
reason
why
I
keep
you
know.
Introducing
the
practical
versus
truly
transparent
distinction
is,
if
I
do
in
the
yellow
world
date,
dot
prototype
got,
get
full-year,
dot
call
and
to
and
I
apply
it
to
a
yellow
proxy
for
a
blue
date
that
will
work
across
around
Andrey
but
will
not
work
across
a
membrane
boundary.
D
D
D
D
Okay,
one
second,
because
it's
a
separate,
invariant
I
when
I
put
it
separately,
we
might
put
headings
in
here
and
do
other
kinds
of
organizing
of
the
information
okay.
So
this
is
a
separate
invariant.
So
I'm
gonna
turn
this
into
a
description
here.
Yes,
okay,
can
you
repeat
what
you
just
said?
Yes,.
B
B
B
B
B
So
promise
dot
resolve
when
applied
to
a
an
object
determines
whether
the
applies
to
an
argument,
the
argument
not
being
the
dist.
It
determines
whether
it's
a
promise,
if
you
apply
it
to
a
proxy
for
a
promise.
It
is
not
the
proxy
for
the
promise
is
not
a
promise
and
the
result
is
that
proxy
got
resolved
applied
to
the
promised
returns.
B
So
this
one
was
fortuitous.
This
one
I
only
noticed
it
after
the
fact
that
the
fact
that
promise
dot
resolve
applies
to
a
non
this
and
the
fact
that
promise
dot
resolve
has
the
venable
assimilation
behavior
the
fact
that
the
one
irregularity
kind
of
cancels
out
the
other
was
just
an
act,
a
happy
accident,
but
it
preserved
practical
transparency
or.
F
I,
don't
want
to
slow
things
down,
but
you
might
want
to
list
as
maybes
promise
that
reject
promise
that
all
promise
that
race,
I
don't
know
if
we
want
to
spend
any
more
time
on
those
I
mean
we're
already
at
two
o'clock
here.
Yeah.
D
We
might
want
to
cut
this
short
because
we
have
talked
about
it
for
an
hour,
but
I
think
we
should
pick
this
up
again
and
you
should
all
feel
totally
free
to
edit
this
set
of
documents
on
your
own
at
any
time.
I
can
also
give
you
a
commit
access,
so
you
can
just
write
whatever
comes
to
mind
a
couple
of
things
that
I
want
to
do.
Maybe
we
can
do
a
second
round
of
this
is
really
clearly
define
the
rationale
for
these
things
like.
C
C
C
I
was
making
a
server
and
I
had
some
clients
and
I
wanted
to
expose
the
you
know,
some
capabilities
from
the
back
end
to
the
clients
over
WebSockets
and
I
was
trying
to
do
it
with
cap,
TP
and
I
found
myself
basically
indulging
and
a
an
exploration
of
what
it's
like
to
build
a
cap,
TP
friendly
application,
and
so
so,
unlike
the
the
conversation
we
were
just
having
I
think
we
were
really
looking
at
what
are
the
constraints
of
the
language?
How
how
clear
can
we
make
a
membrane
here?
C
I'm
really
just
looking
at
what
can
I
practically
achieve
with
you
know
modern
JavaScript
in
terms
of
having
a
framework
that
is
very
friendly
to
to
a
CAF,
TP
type
architecture.
So
so
the
goals
that
I
had
were
that
that
the
the
controllers
or
components
would
be
easy
to
distribute
across
different
processes,
but
it
could
either
be
distributed
or
any
given
aspect
would
be
easy
to
delegate
and
and
so
coding,
locally
or
remotely
should
feel
the
same,
and
so
yeah
yeah.
B
So
I'm
going
to
want
to
unpack
the
feel
the
same
a
lot
because
young
cap
pp
was
designed
for
half
of
that
right.
A
B
It
was
designed
so
that
if
you
treat
any
object
that
you're
treating
as
a
remote,
if
the
object
happens
to
be
local,
everything
should
work
so,
but
if
you're,
if
the
object
is
local,
you
can
access
it
synchronously
and
if
you
do
access
synchronously,
if
you
take
advantage
of
it
slow
being
local,
then
if
it's
actually
remote
there's,
you
know
it
will
not
simply
work.
B
C
Yeah
yeah
that
that
sounds
that
sounds
right
and
reasonable,
and
and
yet
for
the
purpose
of
this
experiment,
I
I
think
I
was
I
was
going
for
be
the
same.
Like
could
I
make
a
local
environment
where
I
was
comfortable
enough
in
it?
That
I
could
take
a
controller
and
pass
it
directly
over
the
network
membrane
and
and
continue
operating
in
the
same
way.
C
So
I've
got
another
little
document
where
I
was
documenting
kind
of
the
constraints
of
cap
TP
right
where,
today,
all
all
records
have
to
be
all
references
passed
over
cap
TB
have
to
be
either
records
or
interfaces,
so
records
being
totally
static,
valued
objects,
interfaces
objects
whose
children
are
only
functions,
and
so
that
was
quickly
the
thing
that
I
hit
so
I
found
that
I
couldn't
pass
most
objects
over
cap
TP
because
of
this
interface,
and
so
I
was
experimenting
with.
What
would
a
you
know?
C
Javascript
object
model,
look
like
that
was
very
friendly
to
its
models
being
passed
over
over
cap
TP,
and
this
means
that
pretty
much
every
object
needs
to
be
an
interface
and
it
can
only
expose
his
records
by
by
getters
or
something
so
anyways.
What
I
came
up
with
it's
something?
Oh
yeah
here
is
a
it's
a
little
github
repo.
It's
called
Caputi
right
now,
it's
very
much
just
a
toy,
but
you
get
this
grain
function
and
you
wrap
it
around
any.
C
Given
JavaScript
primitive,
like
a
string
or
a
number
array,
or
an
object,
pretty
much
anything,
and
that
is
synchronously
available
normally
and
it
exposes.
It
exposes
an
interface
that
let
me
I'll
zoom
in
a
little
bit
more.
There
is
a
notion
of
a
read-only
one
where
it
has
a
get
or
subscribe,
but
if
it's,
if
it's
yours
by
default,
it
actually
also
gives
you
the
ability
to
write
which
includes
a
set
and
of
their
function,
and
and
so
you
get
this
setter
and
better.
C
This
setter
you
get
setters
and
getters,
and
then
there's
also
a
function
for
just
making
it
a
read-only.
The
there
is
is
an
idea
from
mark
where
you'll
see
that
it
well
here
I'll
get
to
there
in
a
second.
It
also
has
a
notion
of
getting
exclusivity,
because
if
we've
got
multiple
clients
who
might
be
operating
in
performing
logic
on
a
remote
value,
they
might
need
to
get
an
exclusive
claim
on
that
value.
So
they
can
update
it
so
basically
wrap
some.
You
text
around
everything,
so
you
can.
C
You
can
get
a
couple
values
mutate
on
it
and
then
release
your
mutex
and
then
and
then
the
editor,
their
function,
which
uses
sess
under
the
hood.
So
you
will
give
you
a
context
to
perform
synchronous
operations
in
the
remote
context
of
the
value.
So
so
this
this
works
the
same,
whether
it's
local
or
remote,
because
it's
now
it's
going
to
return
a
promise.
But
it's
going
to
go
up
to
the
server
where
this
value
is
it
yeah.
Just.
C
C
C
C
There
also
makes
each
of
those
values
synchronously
available
within
it,
which
is
maybe
that's
totally
crazy,
but
that
that
experience
felt
so
good
that
it
started
making
me
think
that,
ideally,
you
could
have
assets
or
resources
from
multiple
different
remote
servers,
and
you
could
have
a
notion
of
calling
their
on
them,
which
would
just
basically,
ideally
this
would
get
locks
on
both
of
the
values
in
some
trusted
environment
and
then
give
you
a
place
to
perform
that
that
atomic
operation,
but
but
you
get
to
program
it
within
this
block
as
if
they
were
synchronously
available,
so
yeah
anyways.
C
G
Have
one
one
one
thing
that
struck
me
is
you've
got
this
get
exclusive
thing
that
that
it
seems
like
what
you
trying
to
control.
There
is
interleaving
and
so
I
don't
know
how
this
works
under
the
hood.
But
but
you
know
a
lot
of
this
can
be
reframed
just
in
terms
of
message.
Order
and
interleaving
patterns.
G
G
This
is
more
like
you
want
to
make
sure
that
these
these
two
messages
get
to
their
destination
without
any
other
message:
traffic
getting
in
the
middle
of
it
and
I'm
wondering
if
I
mean
I'm
sort
of
free
associating
here,
but
I'm
wondering
if
that
the
flow
abstraction
might
be
a
different
way
of
coming
out
the
same
problem.
That's
a
little
less
like
trying
to
do
remote,
locking.
C
Yeah
I
think
for
some
use
cases
that
could
do
it.
I
think
the
locking
was
just
like
the
most
versatile
tool
that
I
could
think
of
to
cover
all
the
use
cases
I
had
where
sometimes
I
might
want
to
operate
on
a
value
when
the
operation
is
itself
asynchronous,
in
which
case
I
need
to
get
the
value
know
that
nothing
else
is
going
to
change
it.
Maybe
that
could
be
done
with
interleaving
and
it's
just
a
different
pattern
of
making
it
I'm
not
sure
how
I
would
expose
it
differently.
Well,.
C
G
Item
but
there
wasn't
a
good
way
to
that's
one
of
the
one
of
the
things
that
Dean's
flow.
Abstraction
specifically
is
intended
to
deal
with
and
I
guess:
I,
don't
completely
understand
it,
but
you
know
next
time
you're
talking
to
him
your
mind.
You
might
take
this
as
a
topic
to
chat
about
yeah
good
well,.
B
So
my
reaction
is,
this
is
kind
of
you
know,
ironically,
going
against
the
grain
the
computation
paradigm,
that
cap
peepees
was
built
to
support
the
computational
paradigm
of
communicating
event
loops.
It's
really
not
trying
to
do
this.
What
this
looks
like
with
the
get
and
set
and
to
get
exclusive
is
more
like
shared
memory
that
you
you've
got
remote
locations,
that
you're
updating
or
read
or
reading,
and
then
you've
got
you
know
semaphores
or
mutual
exclusion
locks
on
for
coordinating,
multiple
updates-
and
I
mean
it's
interesting
that
you
can
I
mean
that's.
B
Obviously,
it's
a
well-understood
well-trodden,
computational
paradigm
for
concurrency,
and
it's
interesting.
The
code
says
straightforwardly
in
to
cap
TP,
but
it's
really
very
far
from
what
cap
DP
was
meant
to
support.
The
idea
is
that
the
interface
objects,
the
interfaces
should
not
be
getters
and
setters
that
they're
not
designed
to
be
getters
and
settings
the
operations.
The
methods
on
the
interface
are
designed
to
be
semantically
coherent
atomic
operations
in
themselves.
B
So
that,
typically
not
always,
but
typically
you
don't
need
atomicity
between
such
operations,
you
need
the
atomicity
within
the
operation,
so
you
send
one
message
across
to
where
the
object
is
the
object
receives
the
message:
does
the
entire
method
in
one
turn
of
the
event
loop,
which
is
therefore
atomic,
and
that?
So
that's
why
the
interface
objects?
Why
that's?
Why
we
have
such
a
strong
distinction?
B
You
know
the
copies.
Don't
stay,
don't
get
out
of
sync
with
each
other
because
they
had
to
be
frozen
in
the
first
place
in
order
to
be
copy,
so
the
records
have
to
be
frozen,
not
just
object,
the
data
properties,
they
have
to
be
frozen,
objects
with
data
properties
and
and
the
result
is
that
we
that
we
never
find
ourselves
doing
any
kind
of
classical
distributed
mutual
exclusion
or
mutual
atomic
or
classic
distributed
atomic
transactions.
B
G
The
object
idea
should
not
be
framed
as
there's
some
state
over
there
and
I'm
going
to
manipulate
it
by
remote
control
because
in
a
distributed
system,
what
you
end
up
having
to
do
is
you
end
up
having
to
you're
your
own
local
model
of
somebody
else's
state
when
it's
in
fact,
the
other
things
job
to
know
what
its
state
is
and
what
you
end
up
doing
there?
Is
you
end
up
building
in
a
bunch
of
coupling
with
how
something
is
structured
internally?
G
F
C
B
B
Multi-Trauma
used
to
have
this
thing:
called
thread
got
stopped
and
they
deprecated
it
and-
and
you
know,
strongly
deprecated.
They
really
wanted
people
to
stop
using
it,
because
any
object
that
that,
where
the
thread
held
the
lock
on
the
object,
when
you
stopped
the
thread,
those
objects
would
just
stay
locked
forever
and
there
was
nothing
you
could
do
about
them.
If
you,
if
you
just
force
the
lock
release,
then
you
had
corrupted
objects
with
no
a
lot
of
them,
which
is
even
worse
than
what
I'm
stay
alive
with
communicating
bed
the
way
we're
using
them.
B
C
You
do
still
have
like,
like
the
memory
leak
problems,
I
mean
I.
Guess
like
we
graph
is
meant
to
fix
that
right.
But
when
you
get
a
reference,
you're
still
responsible
for
releasing
it,
and
that
seems
like
a
kind
of
similar
thing
where
you're
reserving
you
know
listener
status
and
so
I
think
those
both
have
to
be
kind
of
addressed
in
different
ways.
So
you.
B
C
Cool
yeah:
this
is
yeah
that
has
been
very
useful
and
educational
for
me.
Yeah
yeah,
I
think
I
think
just
getting
my
head
into
the
the
paradigm
of
how
this
how
you
would
interact
with
multiple
vats
versus
by
remote
control
or
whatever
I
think,
and
it
gets
a
bit
of
a
mental
shift
that
I
I
another
JavaScript
yeah.
A
Yeah,
we'll
have
to
find
ways
to
do
that.
We
have
to
find
the
part
of
the
new
paradigm
solutions
to
familiar
problems.
Right
I
feel
like
the
the
motivation
for
wanting
to
have
an
accessor
listener
is
probably
because
you
want
to
be
able
to
watch
live
data
and
a
user
interface
yeah
right.
So
this
isn't
something
I've
thought
about
a
lot
of,
but
perhaps
markered
chip.
B
So
there
is
a
so
you
know
this
will
seem
inconsistent.
What
I
was
saying
you
previously
I
I
was
saying
we're
not
trying
to
do
distributed.
Shared
memory,
and
the
exception
to
that
is
the
simplest
Lyneham
which
we've
coated
over
and
over
again,
which
is
what
we
call
the
LAN
port
cell
I
swear.
The
idea
for
such
a
thing
originally
came
from
LAN
port,
but
I
couldn't
find
it.
B
You
know
is
chips,
coinage
and
it's
a
much
more
general
idea.
Then
then
the
particular
use
that
I'm
making
of
it,
but
the
idea
with
a
lamp
or
itself
is
that
you
have
an
object
that
acts
like
a
memory
cell
has
a
get
and
it
has
a
get
method
and
a
set
method.
B
But
when
you
pass
it
through
cat,
near-future,
kappa
p,
kappa
p
enhanced
beyond
the
cap.
Dp
we
have
now
in
this
week
requires
enhancements
at
the
cap
DP
level,
you
can't
build
it
on
the
outside.
This
is
a
third
category.
We
call
pass
by
construction
where
it's
the
original
object,
that
contributes
the
code
or
contributes
instructions
that
says
how
to
construct
its
remote
presence.
B
So
the
remote
presence
is
supposed
to
act
in
some
ways.
Like
the
original
object,
it's
a
shot,
you
could
you
can.
We
also
sometimes
call
it
a
shadow
of
the
original
object
and
the
degree
to
which
it
is
like
the
original
object
is
up
to
the
Europe
is
up
to
that
object
itself.
That's
up
to
the
the
designed
rune
of
nature
of
the
object
in
the
case
of
the
land
port
cell.
What
we're
trying
to
achieve
is
event
consistency,
so
the
shadow
would
have
a
synchronous,
get
method.
B
B
It
gives
you
back
a
value,
that's
as
recent
as
possible,
but
you
should
always
assume
that
it's
not
current
and
then
we
enhance
the
way,
the
LAN
port
cell
with
a
observer
protocol,
which
is
because,
in
order
to
make
lamp-lit
cell
work,
we
internally
had
to
build
an
observer
protocol
anyway.
So
we
then
just
expose
that
observer
protocol
so
that
you
can
then
also
the
lamp
role
cells
have
both
get
and
set,
and
further
methods
for
observing
them
or
asynchronously.
Updating
them
and
I
can
give
pointers
to
the
old
Eve
Lamport
cell
protocol.
B
B
B
C
B
B
C
And
with
some
method
of
watching
it
even
right,
I
guess
cool
yeah,
and
that
does
sound
like
it
sounds
quite
a
bit
like
what
I
made
here,
like.
Maybe
I
made
an
atom
of
a
sort
of
observable,
eventually
consistent
remote,
although
it
doesn't
have
the
synchronous
get
partly
because
it's
a
violation
of
a
current
cap,
CV
invariant
right
yeah,
which
I
guess
just
requires
customizing
at
the
Marshall
layer.
If
I'm
understand
right.
Yes,.
A
In
that
paper
paper
that
essay
I
wrote
on
on
reactive
design
patterns,
so
there's
a
the
critical
distinction
between
different
types
of
data
you
might
put
in
this
kind
of
cell
for
whether
they
model
things
that
are
continuous
are
discretely
changing
and
there
are
implications
for
what
the
network
should
do
with
that
kind
of
data,
depending
on.
If
the.
B
G
F
C
In
the
in
the
current
state
of
this
application,
I
believe
it
waits
for
current
outstanding
new
Texas,
but
it's
it's
a
very
like
naive
interface
right
now.
I
think
that
individual
implementations
would
have
to
have
some
kind
of
unlocking
procedure,
but
yeah
right
now,
it's
it's
a
it's
a
naive
wait!
Your
turn
in
my
kind
of
system.
A
B
B
So
that's
the
definition
of
there
and
this
this
there
is
written
as
a
static
method,
rather
than
a
method
on
a
promise.
So
the
key
is
the
promise
for
a
modern
there.
You
would
say
you
would
have
there
be
a
method
on
P
taking
call
back
and
opt
air
back
as
minutes
so
that
there
seems
more
like
then,
but
the
idea
is
that
the
callback
is
the
success
callback,
but
that's
the
one.
That's
the
function,
that's
going
to
be
sent
to
the
data
and
that
that
function
must
be
a
closed
function.
B
B
B
B
The
source
code
of
a
concise
method,
if
evaluated
out
of
context,
does
not
give
you
back
a
function,
and
it's
also
not
guaranteed
not
to
evaluate
the
weird
edge
cases
where
it
can
evaluate
to
something
unrelated.
So,
let's
ignore
concise
methods,
syntax,
if
you're
doing
a
concise
method.
Syntax,
then
the
stream,
if
ocation
of
callback,
gives
you
back
the
original
method
source
code,
but
the
function
source
code,
which
is
supposed
to
be
a
closed
function.
You're
then
evaluating
it
in
some
foreign
vac
in
particular
the
that.
B
B
A
This
was
the
the
their
method
was
itself
a
thinly
veiled
message
that
gets
sent
as
with
with
their
method
name
and
the
text
of
the
function
to
be
called,
and
the
way
it
would
work
is
that
the
network
would
carry
it
all
the
way
to
where,
wherever
the
promise
was
local,
right
and
and
it
would
be
responsible
for
rehydrating
it
into
a
compartment,
didn't
have
a
compartment
at
the
time
right.
So
it
lays
on
the
shop
floor
still.
A
B
C
So
in
this
example,
I
want
to
I
want
to
add
a
few
exclamation
marks
to
a
value
that
I
don't
have
synchronously
available.
This
is
a
very
contrived
example,
but
since
I
can't
perform
a
lock
on
it
or
if
I
don't
want
to,
and
so
I
could
basically
just
cut
the
locks
out
of
this
library
and
just
preserve
the
there
and
I
can
now
perform
yeah
synchronous
operations
on
something
that's
remote
and
in
the
map
case,
the
same
same
thing.
If
there's
multiple
values
in
this
remote
that
I
can
now
perform
synchronous
looking
code.
C
A
C
A
C
B
The
so,
in
fact,
it's
up
to
do
that
because,
but
the
specification
is
that
you're
only
supposed
to
send
closed
functions
and
the
receiver
is
supposed
to
evaluated
in
an
environment
in
which
the
only
free
variables
are
the
universal
levels.
Now
this
was
before
there
was
an
import
expression,
which
is
a
special
form,
but
by
the
philosophy
of
the
original
design.
I
would
prohibit
the
import
expression
within
this
function,
so
so
Chris
is
right.
B
This
is
not
Map
Reduce,
as
Google
means
Map
Reduce,
its
Map
Reduce,
as
functional
programmers
mean
produce,
which
is
a
frequent
confusion.
But
basically,
this
function
takes
a
an
array
of
elements
where
the
where,
if
sorry
array
of
promises
for
elements
where
the
elements
themselves
are
can
be
anywhere.
So
basically,
this
is
an
array
of
potentially
remote
promises
from
remote
elements,
and
then
it
takes
a
macro
function
which
must
be
a
closed
function
and
it
takes
a
reducer
function
which
does
not
need
to
be
a
closed
function.
B
A
B
B
Buried
in
there
sends
the
mapper
to
the
element
and
gets
back
a
promise
for
the
mapped
result,
and
then
so
as
it
does,
that
in
the
for
loop
up
front.
If
then,
but
doesn't
then,
when
each
of
those
map
results
and
as
each
of
those
then
things
fire
it
does
that
step
of
reduction,
which
is
therefore
reducing
it
only
an
opportunistic
order,
as
those
mapped
P
promises
resolve.
B
So
I
thought
this
is.
You
know,
really
a
very,
very
nice
little
example,
whether
it's
useful
or
not.
It's
certainly
in
the
same
area
as
as
the
kind
of
MapReduce
programming
that
Google
does,
and
just
the
Google
Map
Reduce
has
a
whole
bunch
of
these
sort
of
database
index
kind
of
logic.
That's
really
orthogonal
to
what
I'm
showing
off
here.
C
Yeah
yeah,
that's
that's
a
cool
way
of
composing
it
into
a
bigger,
more
useful
function.
Well,
I've
taken
up
45
minutes
of
the
of
the
last
hour.
I
know
there
was
some
stuff
regarding
tc39.
That
seems
like
such
an
important
topic
to
push
to
the
end,
but
I
just
wanted
to
yield
time.
If
any
of
that
could
be
addressed
with
the
remaining.
C
A
F
Okay,
I'm
not
sure
I'm
able
to
share
my
screen.
I
forgot
whether
I
can
or
not
on
this
thing,
but
considering
we
only
have
about
15
minutes
left.
There
are
three
stage
three
proposals
that
were
relevant
to
this
group.
That
I
saw
the
only
one
that's
up
for
immediate
discussion
in
two
weeks
is
we
graphs
and
I
think
we
talked
about
that
a
few
weeks
ago,
right.
F
F
B
So
that's
what
I
suspected
so
the
answer
about
why
it's
been
languishing
is
it's
my
fault.
Claude
posh
does
not
sit
on
tc39
he's
an
outside
expert.
He
suggested
this
on.
Yes
discuss
and
I
I
expressed
enthusiasm.
He
wrote
off
the
proposal.
I
brought
it
to
committee,
everybody
liked
it
in
advance
until
it
cuts
and
then
I
just
ran
out
of
energy
and
I
just
haven't
gotten
back
to
it.
B
It's
that
all
of
the
JavaScript
engines
conformed
adequately
with
the
proposal
that
the
need
I
had
to
ensure
conformance
his
met,
no
one's
going
to
deviate
from
this
proposal
in
a
way
that's
dangerous
to
us,
and
the
result
was
that
just
never
got
back
to
the
top
of
my
priority
queue
is
somebody
presenting
it
at
the
upcoming
meeting.
No.
B
F
E
E
We
don't
allow
anything
before
that
due
to
concerns
about
needing
to
pre
parse
ahead
of
time
for
some
tools,
CSS
had
a
similar
problem
in
the
web
and
they
are
also
concerns
about
security
and
the
ability
to
accidentally
inject
things
like
a
license.
Comment
affects
how
the
program
runs.
What
about
a
function
body?
What
do
you
mean?
Oh
it's
not
allowed
there.