►
From YouTube: SES-mtg: distributed programming abstractions
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
Okay,
very
good,
so
Dan
and
I
were
starting
to
talk
about
the
whole
remote
computing
framework
given
by
well
suppose.
The
successive
layers
going
up
is
eventual
send
the
EAP
I
and
the
till
dot
syntax,
the
Marshall
layer
and
the
cap
TP
layer
with
together
that
that
stack
turns
JavaScript
into
a
distributed
programming.
Language
where
you
can
use,
tell
dot
to
invoke
remote
objects
and
access
access
fields
of
remote
objects.
A
D
structuring
in
a
way
that
one
could
imagine,
would
eventually
let
us
avoid
the
copying,
but
currently
I
mean
avoid
retrieving
the
entire
object
rather
than
just
the
parts
you're
interested
in,
but
currently
it
does
not
enable
us
to
avoid
the
copy.
So
let
me
actually
find
the
relevant
place
where
the
the
structuring
is
written
up
and
then
I
will
project.
My
screen.
A
C
C
C
C
C
A
A
A
A
B
Yeah
they're,
both
fairly
recent,
so
I,
think
I
think
Michaels,
maintaining
booth,
okay,.
A
Okay,
probably
because
of
different
tools,
trying
to
get
all
these
different
tools
to
recognize,
wavy,
dah,
syntax
different
tools
are
based
on
different
parsers
yeah
yeah,
we're
just
talking
about
that.
This
morning,
yeah
Michaels,
yeah
Michael's,
getting
the
our
prettier
or
there's
Michael,
so
Michael
I
was
just
explaining
about
how
you're
getting
the
till
dot
support
into
our
use
of
various
tools,
and
we
were
is
so
we're
wondering.
First
of
all
which
repositories
we
found
both
transform
eventual
send
and
acorn
eventual
Center.
Those
the
right
to
repositories
are.
B
B
A
B
A
A
B
I
think
the
only
way
when
you're
just
using
node
is
to
do
some
kind
of
rewrite,
and
there
are
there
ways
of
doing
a
babel
rewrite.
For
example,
I'm.
Just
not
I
haven't
done
this
for
a
while,
though
okay.
A
So
the
so
the
the
topic
we
started
with
is
dan
has
been
looking
at
our
cap
teepee
and
comparing
what
the
functionality
we
provide
with,
what
he's
currently
doing
now
and
thinking
about
switching
over
from
what
he's
doing
now
to
cap
T
P
and
what
are
some
of
the
enhancements
to
cap
T
PE.
That
would
be
good
for
cap
T
P.
That
would
also
help
dance,
which
is
that
a
fair
summary.
B
Yeah
yeah
I
think
I
think
that
basically
I've
found
that
capped.
If
he
was
doing
it
had
basically
the
exact
same
layer
of
the
stack
goals
that
this
module
I
was
working
on
had
and
I.
Think
the
only
the
only
advantage
that
I
have
left
for
mine
is
is
just
a
ergonomics
of
not
needing
the
the
e,
but
but
with
the
ax
transform
I.
Guess
you
don't
need
to
eat,
you
get
the
eventual
send
and
with
pipelining
there's
some
very,
very
big
benefits
to
doing
that.
A
A
notational
principle
that
I've
come
very
strongly
to
believe
in
is
that
you
should
be
able
to
tell
at
the
call
site
without
having
to
look
things
up
elsewhere,
whether
you're
looking
at
an
immediate
call
or
an
eventual
set,
and
the
reason
is
that
in
their
typical
cases
they
have
very,
very
different
side
effect
contracts
and
also
the
eventual
send
provides
you
a
strong
guarantee
against
interleaving,
so
either
the
capital
e
syntax
or
the
tell
dot
syntax.
In
both
cases,
you
can
just
tell
looking
at
the
call
side
that
what
you're
seeing
is
something
eventual.
A
If
your,
if
so,
you
can
certainly
invoke
a
local
method
with
dot
that
returns
a
promise,
but
the
method
itself
executes
now
it
executes
during
your
turn
and
it
runs
to
complete
lease.
The
synchronous
part
of
it
runs
to
completion
before
it
returns.
So
you've
got
potential,
reentrant
see
there,
and
sometimes
that
sometimes
that's
what
you
want.
But
if
you
see
an
eventual
send,
then
you
know
that,
no
matter
what
it
is
you're
invoking
it
can't
disrupt
what
you're
doing
during
this
turn.
A
A
Good
well,
thank
you
yeah.
So
a
question
that
Dan
asked
about
the
destructuring
is:
is
it
conceivable
that,
by
changing
something
about
cap,
DP
and
Marshall,
we
could
successfully
turn
a
destructuring
gate
like
this
into
something
that
only
fetches
the
the
things
named
and
doesn't
cause
the
overhead
of
fetching
the
additional?
D
This
sounds
very
much
like
the
the
issue
of
doing
a
method,
call
where
you
wanted
to
know
that
you're
going
to
be
calling
so
that
you
didn't
have
an
extra
round
trip
for
you
know,
first
fetching
a
reference
to
the
method
and
then
invoking
the
method.
This
feels
like
a
very
similar
kind
of
question,
but
with
a
wider
variety
of
different
ways,
it
can
manifest
itself.
A
Right
so
the
so
so
the
so
that's
a
good
point,
which
is
with
our
pipeline
message,
sends
it
is
the
case
that
a
structure
of
objects
that
are
connected
to
each
other
only
by
method,
behavior
you
by
sending
a
a
by
sending
a
expression
tree
of
those
method,
calls
promise
pipelining
tranced.
It
turns
it
into
one
round-trip,
but
it's
a
round-trip
that
only
fetches
what
you
asked
for
with
the
eventual
get.
A
As
far
as
the
low-level
semantics
of
what
we
proposed
to
the
committee,
it
could
do
that
as
well
with
regard
to
the
actual
behavior
of
CAP,
TP
and
Marshall,
the
we
divide
objects
into
pass
by
copy
and
past.
By
presents
past
my
presence,
meaning
you
know,
said
right
now,
meaning
set
and
always
send
remote
messages
to
the
actual
object,
and
this
would
still
be
the
invocation
of
Bob
P
tilde
whew.
A
A
A
B
Was
actually
something
similar
to
a
distributed
file
system
API
in
the
late
90s
it's
cluster
and
basically
they
had
something
called
intense.
So
when
you
open
something,
you
told
it
to
I
didn't
tend
to
read
it
do
I
intend
to
write
it.
Do
I
intend
to
do
whatever
else,
and
it
was
a.
It
was
essentially
a
way
of
avoiding
those
round
trips
to
say:
yes,
that's
what
I'm
going
to
do
with
it.
So
only
don't
bother
contacting
the
metadata
server.
I,
don't
want
to
know
the
size
of
it.
B
I
just
want
to
know
the
object
directly,
but
it's
it's
messy
like
as
chip
said,
you
know
it's
it
really.
B
A
B
B
B
A
But
so
likewise,
if
you
just
did
an
immediate
get
of
an
out
of
bound
out
out
of
bounds
array
index,
a
JavaScript
array
would
also
give
undefined
okay.
So
here's
a
untested
speculation,
which
is
as
long
as
it's
an
array
like
like
you're,
showing
it
would
just
fetch
the
indices.
But
if
the
array
pattern
contains
a
triple
dot,
then
it
would
ask
for.
C
So
sorry,
it
seems
like
I
was
distracted
and
I
on
a
few
were,
but
I
just
noticed
one
thing
about
the
example
and
I
think
Michael.
He
already
talked
about
this
once
before
about
whether
or
not
it's
assumed
asynchronous
or
were
explicitly
awaited,
so
an
eventual
send
at
this
point
there
is
no
wait
on
the
example
on
the
screen
and
so
would
await
fit
somewhere
here
or
is
there
something
I
miss
so.
B
A
If
you
did,
if
you
did
the
what
you
expect
to
do
with
the
wait
where
you
say,
constant,
open
square
bracket,
X
comma
y
equals
a
weight
of
Bob
P
tilde
to
the
pop
Bob
he'd.
Tell
doc.
Foo
is
still
doing
an
eventual
send
to
Bob
P,
which
is
remote,
but
the
await
forces
a
round-trip.
So
you
lose.
You
lose
promise
pipelining
doing
the
await.
Yeah,
also
something
that
I'm
increasingly
suspicious
of
as
I
encounter
awaits
in
the
code
that
agaric
has
written
and
as
I
encounter
external
explanations
about
use.
A
A
C
It
could
be
generator
or
not
doesn't
matter
so
I
think
I,
think
a
weight
kind
of
like
restricts
what
you
can
do
with
promises.
But
if
you
don't
design,
you
know
to
utilize
what
you
cannot
await
from
promises,
then
you
can,
you
know,
live
all
your
life
as
a
happy
developer
and
never
even
see
what
you
miss
so,
but
I
think
there
it's
just
just
whether
or
not
people
are
using
the
features
as
sugar
or
as
features
so.
A
Are
then
modified
by
arbitrary
other
intro
labels?
Other
turns
be
in
the
interval
from
before
the
awaits
until
after
the
you
ate
and
if
people
don't
know
that,
then
they'll
write
code
where
they're
doing
something
with
state
before
the
await
and
then
make
unser
incorrect
assumptions
about
what
state
has
state
has
has
remained
stable
on
the
other
side
of
the
await
yeah.
D
I
mean
I
think
my
experience
watching
what
people
do
is
it's
not
that
they
aren't
aware
that
there's
an
interleague
point
there,
it's
that!
That's
you
know
one
of
the
first
things
they're
taught
as
part
of
becoming
familiar
with
this
weight
feature
and
it's
kind
of
like
yeah
yeah,
and
then
they
put
and
then
and
then
they
forget
it
again.
A
D
A
D
A
B
B
Yeah,
which
makes
it
really
fun
to
try
to
solve
one
of
those
problems
in
the
noid
based
code
base.
You
have
to
design
all
kinds
of
data
structures
just
to
do.
Synchronization
again.
Oh
really,
I
I
was
in
the
middle
of
that
in
my
previous
job,
because
we
were
using
the
weight
all
over
the
place,
so
it
was
and
you're
working
great,
oh,
but
we
have
this
server.
That's
a
bunch
gets
the
order
wrong.
D
Once
you
put
in
one
away,
it
tends
to
trigger
the
addition
of
lots,
more
awaits
that
aren't
actually
by
any
means
strictly
necessary,
except
to
satisfy
the
fact
that
that
things
get
turned
into
into
async
functions
which
didn't
need
to
be,
but
they
need
to
be
async
functions,
because
you
can
only
use
a
weight
inside
an
async
function,
but
now
their
return
is
now
a
promise.
So
they
have
to
be
called
with
promise
handling
semantics,
and
so
their
collars
get
wrapped
in
a
sink
functions
in
it.
Just
like
I
say
it's
contagious.
A
A
So
any
case
we
got,
we
got
the
higher
levels
all
working
in
time
to
do
that
kind
of
distributed
smart
contracting.
Well
what
we
did
it
without
trying
to
avoid
async/await,
and
we
ended
up
with
some
race
conditions,
exactly
where
you
would
expect
from
this,
ignore
ignoring
of
awake
being
a
interleaving
point
and
having
atomicity
expectations
that
are
invalidated
by
by
in
a
way.
A
And
that
those
pain
points
might
teach
us
that
there
are
actually
some
uses
of
async/await
that
are
actually
good
uses,
because
the
reason
why
I
you
know
my
paranoia
about
async/await
went
down
for
a
long
time
is
because
a
lot
of
complex
promise
code
actually
does
read
more
simply
and
there's
an
aspect
of
logic.
That's
clearer
when
reading
async
functions
with
the
waves,
especially
when
they're
sort
of
complex
control
that
you
have
to
encode
by
other
means.
A
So
so,
even
though
there's
in
one
way
using
explicit
promises,
reduces
the
likelihood
of
certain
kinds
of
bugs,
because
the
code
is
harder
to
follow,
it
increases
the
likelihood
of
other
bugs
and
I
think.
The
only
way
we're
going
to
figure
this
out
is
by
trying
to
do
this
conversion
and
seeing
where
it
hurts
yeah.
D
Async
and
a
weight
were
available
in
the
language
where
you
have
to
just
basically
do
all
the
the
you
know
the
the
resolution
plumbing
yourself
having
a
library
which
made
that
much
less
painful
made
it
less
likely
that
you
just
put
in
and
away
because
that
was
just
sort
of
the
lazy,
easy
way
to
deal
with.
The
fact
that
you
had
a
thing.
It
was
returning
a
promise
so.
A
A
Because
that,
because
in
general,
that's
you
know
the
other
approach
to
you
know.
The
first
line
of
defense
against
identifying
the
painful
cases
is
what
are
the
missing
abstractions
mm-hmm
agree
to
which
we
can
provide
the
missing
the
missing
abstractions
in
libraries
rather
than
having
people
go
back
to
async/await
I.
Think
that
would
be
good.
D
C
So
my
question
I
guess
to
Michael
at
this
point,
was
like
how
do
you
know
that
the
assignment
took
place
and
then
you
would
just
wrap
this
assignment
in
parentheses
and
it's
basically
an
expression.
Their
returns
promises.
Not
yes,
oh
so.
Is
that
still
how
it's
going
to
be?
Or
is
that,
like
the
permanent
state.
A
A
C
Sorry,
sorry
so
I
just
wanted
to
take
that
example,
one
step
further.
Sometimes
you
do
an
assignment
and
you
chain,
your
assignments
like
you
want
to
assign
on
three
or
four
different
objects
or
on
the
same
object
with
different
keys,
one
value
and
obviously
till
dot
having
an
assignment
component
to
it.
Some
people
will
want
to
try
to
change
a
sign,
or
you
know
at
least
we'd
want
to
know
how
how
to
imagine
the
flow
there.
C
B
So
in
general,
when
you're
dealing
with
promises,
I
find
that
it's
best
to
have
intermediate
values
actually
assigned
to
variables.
If
you
want
to
reuse
them
for
stuff
and
just
because
you
can
only
set
then
on
a
promise
once
because
once
you've
done
it,
you
can't
do
it
again
unless
you
have
a
reference
to
that
original
value
again,.
C
Like
we'd
be
apparent
semantics
of
its
being
that
the
assignment
occurred,
but
rather
you're
writing
an
expression
that
looks
like
an
assignment
so
so
in
your
mind,
you're
working,
you
know,
based
on
the
on
what
on
how
the
syntax
looks.
It
looks
like
an
assignment.
You
know
it's
a
bit
different,
but
your
mind
will
be
attracted
to
thing
there.
So
so
is
there
may
be
room
to
explore
whether
or
not
something
can
be
made
to
at
least
consider
chaining
or
at
least
make
it
very,
very
clear.
You
shouldn't.
A
I've
the
issue
about
what
to
recommend
is
a
good
question,
because
I
have
never
wanted
to
use
remote
property
assignment
and
I've
never
wanted
to
use
remote
property
deletion.
The
only
things
that
I
ever
actually
do
eventually
are
our
invitations
and
property
gets
and
the
event
the
and,
in
fact
our
higher
levels,
cap,
T,
P
and
Marshall
last
I
knew
only
supported
invitations
and
gets
the
reason
why
the
others
are
in
the
tc39
proposal
is
largely.
A
In
order
to
have
the
proposal
as
a
whole
fit
into
the
language
in
a
more
natural
way,
so
that
there's
so
that
what
you
would
expect
to
be
there
by
symmetry
with
the
rest
of
the
language,
is
there
if
it
doesn't
conflict
with
any
principle
and
the
eventual
assignment
and
eventual
delete,
doesn't
conflict
with
any
principle.
I
want
to
solve.
I
wanted
to
direct
your
attention
to
the
line.
I
just
typed
into
chat,
which
is
the
when
X
is
local.
The
X
tilde
equals
V
is
essentially
equivalent
to
X
dot.
A
A
B
A
C
Until
today,
they
all
happened
on
the
same
paradigm,
you're
assigning
from
the
right-hand
side
of
the
left
hand
side.
But
when
you
chain
assign,
from
the
right
hand
side
to
the
left
hand,
side
everything
on
the
left
hand,
side
is
assigned
the
you
know
the
most
right
hand,
side
value.
Irrespective
of
whether
or
not
these
properties,
you
know
have
getters
that
change
that
value
or
not
along
the
way.
It's
not
like
you
assign
it
to
the
first
and
then
you
get
it
back
and
and
that
get
could
actually
be
different
than
what
was
the
sign.
C
C
You
would
have
a
an
internal
field
on
the
promise
that
says
the
right
hand,
side
value
that
you
know
triggered
this.
Was
this,
and
so
you
know
the
next
to
Bob
assignment
outwards
would
actually,
regardless
of
the
promise,
because
there
were
no
awaits
there
were
nothing
to
indicate
that
you
wanted
to
actually
do
anything
other
than
sign.
Then
you
would
actually
think
that
internal
field,
which
is
the
most
right
hand,
side
value.
C
A
D
C
A
So,
in
the
the
expression
I
just
wrote
down,
extol
dot,
foo
equals
y
tilde
bar
equals
V
the
with
the
expansion
that
we
currently
have
the
yl
dot
V
as
and
also
again
just
for
clarity,
assume
everything's
local.
Let's
not
worry
about
from
the
remote
case.
If
everything
is
local,
then
the
white
L
dot
equal
V
has
the
expansion
in
to
then
that
I
showed
earlier,
and
therefore
the
value
of
that
expression
is
itself
a
promise
for
what
the
Avani
assignment
return.
A
What
the
assignment
will
return
will
be
the
value
of
V,
but
therefore
the
right-hand
side
of
the
outer
equals
the
value
of
that
right-hand
side
is
not
V.
It's
a
promise
for
V.
Now
what
that
means
is
that
the
outer
assignment
will
do
adopt
then
on
X
to
eventually
assign
two
x's
fulfilment,
dot
foo.
But
the
thing
that
it's
going
to
eventually
assign
to
foo
is
not
V.
C
Yeah
I
count
us
people,
but
I
I,
don't
speak
for
people
so
yeah
like
for
me.
I
know.
I
know
like
this
feels
like,
like
you
know,
if
I'm
doing
D
as
the
right
most
whatever,
and
there
are
equal
signs,
that
I
would
not
have
expected
that
one
of
the
assignments
x2
dot
foo
is
all
of
a
sudden
a
rejected
promise,
as
opposed
to
being
deep
is
that
that
allowed
the
intermediate
assignment
to
influence
okay?
What
is
that
X?
Tilde?
Okay.
A
B
Think
to
make
this
a
bit
better,
we
could
introduce
the
idea
of
an
T
result.
I
have
to
say
that
when
because
because
what's
happening,
is
ideas
being
passed
as
an
argument
to
these
assignments
right
and
when
V
is
local,
we
want
actually
the
local
thing.
We
don't
like
the
promise
for
the
local
thing.
A
B
C
B
D
C
C
C
B
A
B
I'm
not
sure
I'm
going
with
this
and
I
I
guess
what
I
was
wondering
is:
can
we
recapture
some
of
the
local
semantics
by
as
Saleh
was
describing?
He
was
saying
putting
a
slot
on
the
promise
for
the
right-hand
side,
but
the
way
you've
described
that
before
Marcus
is
essentially
what
aunty
resolve
does.
Is
it
takes
a
promise
and
gives
you
back
what
it
was
resolved
with.
A
Yes,
it
doesn't
do
it,
obviously,
by
putting
a
slot
on
it,
I
mean
not
in
a
visible
property
on
it,
but
it
doesn't
buy
the
dunya.
But
yes,
it
does
do
it
by
the
equivalent
of
sort
of
putting
an
internal
slot
on
it,
but
but
using
a
week
map.
Instead,
the
Boyd
do
I
not
want
to
introduce
aunty
resolve
into
these
some
into
the
semantics.
This
low-level
yeah.
D
A
D
D
A
A
B
A
D
You
jumped
in
on
either
the
the
the
argument
for
having
them
is
orthogonal
T,
which
is
very
appealing
at
a
kind
of
a
surface
level.
Yeah
the
event
argument
for
taking
them
out
is
actually
it's
a
semantic
swamp
and
I.
Think
the
semantics
swamp
argument
is
stronger
in
terms
of
the
deep
rationale
for
this
language
feature,
but
poses
you
a
challenge
of
how
do
you
respond
to
people
who
aren't
evaluating
the
proposal
in
a
deep
way
and
are
therefore
saying
well
you've
got
this
these
things?
D
C
And
when
you
withdraw,
it
is
actually
a
good
way
to
get
the
attention
of
those
who
will
not
go
deep
enough
to
have
noticed
that
yeah.
So
so
so
it's
it's
good
that
it's
actually
out
there
and
it's
good.
It
speaks
volumes
that
you
actually
say.
We
want
to
think
a
little
bit
on
that,
at
least
for
now.
So
let's
put
it
aside
and
revisit
right,
so
so
I
think
this
way
it
becomes
more
obvious
that
there
will
be
careful
considerations
to
be
made
for
other
features.
A
D
I'm
tentatively
in
favor
of
that
I
think
the
argument
for
set
is
pretty
much
a
slam-dunk
I
think
the
argument
for
has
is
basically
well.
We
don't
have
dot
associated
with
as
anywhere
else
so
might
as
well.
Get
rid
of
it
here.
Delete
I
think
is
probably
it's
probably
not
a
problem
to
leave
it
in
there's,
probably
not
a
problem
to
take
it
out.
I
think
taking
it
out
is
results
in
something
which
is
simpler,
which
is
better.
D
A
B
A
A
B
A
B
A
B
I
am
okay,
okay,
good,
so
they're
they're
talking
about
you
want
to
chain
things
together,
so
rather
than
chaining
by
the
callbacks
and
then
using
the
results
of
the
callbacks
and
then
throwing
stuff
and
doing
all
that
you,
you
define
objects
that
are
the
operations
that
you
want
to
do.
So
each
of
these
objects
can
be
instantiated
with
some
arguments
and
then
some
of
those
arguments
can
be
async
objects,
and
some
of
them
can
be
just
plain:
regular
objects
or
regular
values.
B
B
B
A
B
B
B
The
payoff
that
they're
aiming
for
is
that,
if
you
have
an
operation
like
FS
right
file
about
right
file,
then
you
can
wrap
it
in
a
missing
object
and
then
it's
arguments
could
be
promises
or
they
can
be
other
async
objects
or
just
regular
functions.
So
from
then
on.
You
don't
use
FS
to
write
file
at
all.
You
only
use
the
ASIC
object
version
and
it's
this
punning
on
arguments
could
be
promises
or
their
objects
or
sorry
could
be
a
sick
objects
or
or
synchronous
values,
and
that.
A
B
B
C
C
B
C
B
A
C
If
you
eat
sing
caller
for
the
generator
and
every
time
it
gets
a
promise,
it
awaits
the
promise
before
it
takes
the
next
cycle.
Of
that
generator
I
mean
there
are
patterns
that
you
know
are
trying
to
use
language
features
to
deliver.
The
same
kind
of
like
all
functions
are
synchronous
because
they
only
get
called
and
the
promise
they
need
is
resolved.
A
So
because
this
depends
on
the
resolution
of
all
of
the
argument
promises
before
something
is
called
the
you
would
never
do
a
stateful
update
this
way,
because
the
order
in
which
these
things
are
called
is
not
something
you
would
want
to
predict.
You
would
not
want
to
depend
on
the
order
in
which
these
things
are
called
if
they're
held
back
by
by
any
element
of
their
tree
being
in
their
tree
of
arguments
being
not
yet
resolved.
B
A
A
In
one
of
the
express
the
issue
about
the
deposit
methods
and
the
argument
purse
and
in
one
of
the
publications
showing
the
pattern,
the
one
in
distribute
electronic
writes
in
JavaScript
I
have
the
deposit
method
internally?
Do
a
dot
then
on
this
on
the
argument
purse,
so
that
you
can
pass
in
a
promise
for
the
argument.
Purse
and
the
deposit
doesn't
proceed
until
the
promise
resolves
right
and
that
that
made
and
it
was
interesting.
The
effect
that
has
on
the
clients
is
that
it
has
both
the
pro
or
a
con
on
the
problem.
A
The
clients,
which
is
the
client
no
longer
needed
to
resolve,
argument
promises
directly
before
passing
them
in
to
deposit,
because
deposit
would
would
do
its
own
pausing
waiting
for
them
to
resolve.
But
it
was
exactly
at
the
price
of
not
being
able
to
count
on
the
deposit
happening
before
the
next
message
that
you
sent
in.
B
A
And
we
we
found
over
time
is
that
I
mean
that
that
one's
explicitly
and
necessarily
a
stateful
update
it's
sort
of
inherent
in
the
semantics
that
as
a
stateful
update
so
I
suppose
it's
not
surprising
there
that
the
loss
of
guaranteed
order
was
the
bigger
deal
rather
than
waiting
for
arguments
to
resolve.
Yeah.
D
I
think
what
this
thing
is
doing
is
its
allowing
you
to
express
causal
dependency
using
the
syntax
that
you
would
otherwise,
ordinarily
use
for
for
for
capturing
the
the
order
of
operations,
and
so
I
think
there
is
a
there
is
a
there's
sort
of
a
gang
in
expressiveness
that
is,
that
has
had
at
the
cost
of
a
a
loss
in
the
clarity
of
the
semantics
of
what
it
called
means.
Yeah.
B
Because
your
your
your
reifying
all
these
things
and
then
you're
dealing
just
with
a
tree
of
objects
instead
of
a
tree
of
calls
which
has
its
own
problems,
are
it.
It
takes
us
further
away
from
the
whole
promise,
then
world,
where
you
know
that
you're
dealing
with
the
promise,
so
you
do
something
about
it
versus
I.
Just
want
to
do
this
operation
I!
Don't
care
how
it
happens,
it
has
to
happen
in
order
right.
D
A
A
If
you
pass
them
a
promise
as
an
argument,
then
they
receive
a
promise
as
an
argument
and
they
can
do
they
can
decide
to
like,
like
the
deposit
I
just
described,
they
could
decide
to
postpone
the
rest
of
their
internal
logic
waiting
for
it,
but
sometimes
you
actually
want
to
receive
the
promise
to
do
something
with
it,
the
stored
in
the
data
structure
or
whatever,
rather
than
wait
for
the
promise
to
resolve.
First.
B
To
me
to
me,
this
was
a
motivator
for
promised
at
all,
and
what
you
were
saying
with
all
comparable
before
yeah
I
could
take
any
any
arbitrary
structure.
Then
you
can,
then
you
can
wire
up
to
then
to
just
make
the
best.
You
study
the
structure
that
you
that
you
put
into
it
mmm-hmm,
rather
than
with
promised,
are
all
having
to
pick
them
out
linearly
and
then
reassemble
them.
A
C
Not
not
you
know
the
eventual
cent
I
I
wondered
if
there
could
be
a
way
to
you
know,
introduce
in
the
language
away
for
a
promise,
or
you
know
a
promise
like
someone
are
controlling
the
faith
of
a
promise
to
know
whether
or
not
another
promise
is
part
of
the
chain
for
this
you
know
so
the
promises
in
the
chain
of
another
promise,
then
you
would
await
the
one
you
know
that
is
bigger,
so
so
this
is
to
avoid
deadlocks.
Okay,.
A
B
B
And
where
the
supplies
in
the
eventual
same
proposal
is
that
we're
going
to
need
that
eventually?
Because
that's
that's
that's
how
we
can
do
promise
pipelining
in
the
event
that
promises
are
forwarded
to
something
else,
yeah.
B
B
A
A
A
Then
then,
a
membrane
like
semantics
you're,
not
trying
to
preserve
transparency
in
JavaScript
you're,
defining
sort
of
this
higher
level.
Remote
object
semantics.
So
if
you
pass
the
same
pass
by
copy
object
twice,
it
might
arrive
as
two
different
copies
that
are
otherwise
identical,
but
have
different
object.
Identity,
so
pass
by
copy
objects,
are
you're
not
supposed
to
pay
attention
for
their
identity
passed
by
presence
objects.
A
The
there
is
a
remote
thing
called
the
presence
that
is
supposed
to
have
supposed
to
be
the
one
for
one
identity
as
the
past
by
presence
object
that
it
designates.
So
those
things
have
reliable,
unforgeable
identity
that
are
one
for
one
and
then
promises
are
when
they
appear
in
the
structure
are
also
things
where,
where
you're
not
supposed
to
pay
attention
to
their
identity,
if
the
same
promise
is
passed
to
a
counterparty
multiple
times,
it
might
arrive
as
different
promises
that
are
behaviorally,
essentially
identical.
A
A
However,
promises,
if
encountered
fall
into
neither
of
those
categories,
you
don't
yet
know
what
they're
a
promise
for,
so
you
can't
recur
into
them
to
do
a
structural
compare
and
you,
and
likewise,
if
there
are
promised
or
something
with
identity.
You
don't
know
what
that
identity
is,
and
you
should
not
use
the
promise
identity.
So
we
define
this
operation
that
I'm
pleased
to
say,
all
of
which
fits
on
the
screen
called
all
comparable,
which
is
kind
of
a
pun
on
promise
dot.
A
All
promise
that
all
is
shallow
for
one
level
of
array-
and
this
is
deep
through
all
paths
by
copy
structures,
but
had
performed
sort
of
the
same
treatment
of
promises
on
the
fringe,
but
but
does
that
treatment
also
deeply?
So
if
you
give
it
a
passable
object,
I
thing
that
obeys
all
of
the
rules
of
pass
ability
that
I
enumerated
and
such
that
all
of
the
promises
in
the
structure
when
they
fulfill
will
fulfill
two
things
that
are
themselves
passable
recursively.
A
If
you.
So,
if
you
give
it
such
a
passable
thing,
then
it
gives
you
back
a
promise
for
a
comparable.
A
comparable
is
a
passable
in
which
the
the
leaves
of
the
passed
by
copy
tree
are
only
things
with
that
are
primitive
values
or
have
reliable
identity.
Ie
passed
by
presents
things
so
so,
first
of
all
did
all
of
that
make
sense
I
that
would
sound.
Look
like
a
big
run-on
sentence.
A
B
A
A
D
Well,
I
mean
this:
is
this
is
kind
of
figures
into
my
standard
explanation
of
why
promise
pipelining
is
power
this?
Basically,
it
allows
you
to
to
not
look
at
the
value
until
you
actually
need
to
look
at
the
value.
You
actually
need
the
right,
but
in
this
case
the
one
thing
which
feels
weird
to
me
is
presence,
and
that
is
because.
D
A
A
Right
presence
is
and
is
a
remote
non
promise
object
that
has
identity
and,
in
particular,
when
you
do
on
a
remote
promise.
You
do
with
this.
This
is
actually
the
way
in
which
we
derive
the
need
for
an
explicit
presence.
Object
is
if
you
have
a
remote.
If
you
have
a
remote
promise
and
you
do
a
dot,
then
on
it
you,
if
they're
remote
promise,
once
the
remote
promise
is
fulfilled
to
a
remote
object.
D
A
A
You
yep
one
thing:
that's
weird
about
the
classification
here
passed
style
of
online
52
is
named
that
in
order
to
suggest
an
analogy
to
type
of
it's
giving
you
the
classification,
according
to
the
remote
object,
semantics
that
are
Marshall
and
cap,
TP
define
and
pass
style
of
does
not
distinguish
a
pass-by
presence,
object
from
a
presence
and
I
think
preparing
for
the
future.
That's
a
good
idea,
but
it's
certainly
surprising.
A
A
The
cap
TP
layer
in
order
to
Ho
something
more
like
the
unum
presences,
which
also
relates
to
something
that
Dan
Finley,
said
I
think
right
before
we
turned
recording
on.
So
let
me
so.
Chip
originated
the
unum
model,
so
I'll
say
a
bit
about
how
I
see
it
fitting
into
here,
but
then
I'll.
Let
chip
explain
you
in
a
model.
A
Understands
that
a
remote
representative
of
it
is
going
to
be
constructed,
it
might
want
that
remote
representative
to
be
something
that
that,
at
that
remote
site
is
more
expressive
than
just
an
empty
object
and
can
satisfy
some
queries
locally.
So,
if
there's
you
know
some
something:
that's,
for
example,
a
stable,
a
stable
piece
of
state
that
it
might
duplicate
the
state
on
the
remote
presence
and
then
provide
a
method
on
the
remote
presence
that
depends
only
on
the
remote
state
so
that
somebody
with
that
presence
could
actually
do
dot
on
it.
A
So
in
a
we
call,
this
passed
by
construction,
which
is
to
say
that,
as
opposed
to
pass
by
pass
by
copy,
is
that
the
original
pass
by
presence
object
explains
to
the
comm
system,
how
to
construct
a
remote
representative
of
itself
on
the
other
side.
So
I
don't
have
any
concrete
plans
to
do
that,
but
I
anticipate.
We
will
eventually
do
that.
C
I'm
sorry,
a
quick
question
here,
because
I
this
relates
very
much
to
the
idea
that
I
was
trying
to
reappropriation
under
bar
underbar,
proto
and
JSON
I,
guess,
parsing
and
I
was
thinking.
You
would
want
to
import
the
module
that
exports.
The
class
of
that
particular
object
rather
than
to
actually
pass
the
prototype
itself
and
somehow
we,
you
know,
ensure
that
it
actually
nests
as
the
prototype.
And
this
way
you
would
actually
not
be
duplicating
all
the
prototypes
yeah.
A
You've
you've
you've
identified
exactly
the
the
area
that
makes
pass
by
construction
hard,
which
is
the
remote
object,
can
only
have
behavior
if
there
is
remote
code
to
give
it
behavior
and
the
remote
code
would
have
to
be
selected
by
the
past
by
presence
object
explaining
how
to
construct
it,
and
that
means
there
has
to
be
some
kind
of
shared
namespace
or
something
such
that
once
I
can
explain
what
code
to
use
on
the
other
side.
Well,
you
are
you.
D
Need
to
either
either
have
some
way
of
making
reference
to
something
which
you
know
to
exist
on
the
other
side,
and
presumably
this
is
by
pre
agreement
on
what
that
set
of
things
would
be,
or
you
need
some
way
to
convey,
along
with
the
description
of
a
thing,
to
convey
that
code
itself
as
part
of
what
you
you
deliver
as
the
bundle
of
stuff
which
now
gets
into
you
know
all
the
sort
of
remote
module
loading
in
and
yeah
odhh
transport.
All
of
that
cannon
works.
A
Yes,
so
that
this
is
so
right
now
at
outside
of
the
comm
system,
the
gorrik
smart
contracting
support
has
a
essentially
a
special-purpose
hand
encoding
of
this
kind
of
remote
code
binding
in
one
special
case,
which
is
what
we
call
extent
ops
and
the
key
thing
about
extent.
Ops
is
that
there
is
very,
very
few
pieces
of
code
that
that
that
currently
exists
that
provides
sort
of
a
menu
of
behaviors
to
select
from
and.
D
Yeah,
there's
lots
of
really
interesting
unsolved
problems
there
between
kind
of
got
a
fingernails
grasp
on
you
know
a
hint
at
the
tantalizing
possibility
of
there
might
be
a
solution
to
this
problem,
but
absent
a
both
a
compelling
use
case
and
an
immediate,
but
you
know
an
immediate
need
and
resources
to
divert
to
investigating
this.
It
kind
of
remains
this
sort
of
tantalizing
possibility
off
of
the
distance
right.
A
And
the
the
wonderful
thing
about
a
goreck
strategy
with
regard
to
these
issues
as
as
a
business
and
as
somebody
you
know
as
a
company
trying
to
deliver
a
smart
contracting
platform
is
that
we
found
that
we
could
practically
do
everything
we
actually
needed
to
do
without
solving
this
problem.
So
we're
going
to
leave
this
problem
postponed,
probably
for
a
good
long
time.
D
Right
well,
in
fact,
and
in
fact,
the
way
we
solve
this
problem
in
in
habitat
back
at
the
dawn
of
you
know.
History,
which
is
where
the
human
model
came
from
in
the
first
place,
was
that
every
client
had
distributed
to
it,
a
disc
that
contained
the
definitions
of
all
of
the
resources
that
were
available
to
assemble
stuff
from
and
and
as
a
special
case
solution
to
almost
any
specific
business
problem.
That
may
be
sufficient.
C
D
A
A
Because
the
way
you
solve
the
you
know,
the
truss
problems
that
would
be
created
by
trying
to
have
global
coordination
or
a
namespace
is
just
don't:
have
global
coordination
or
a
namespace,
and
then
the
abstractions
that
turn
this
low-level
distributed.
Object
semantics
into
an
enum
semantics
can
be
abstractions
that
are
built
on
top
of
this
layer
where
multiple
different
ones
can
be
built
on
top
of
the
same
comm
system.
So
they
don't
have
to
coordinate
on
a
namespace
with
each
other.
D
A
C
A
Michael
with
regard
to
the
async
tree,
abstraction
yeah,
the
to
what
degree
would
how
much
of
the
benefit
of
that
would
we
get
in
a
piece
of
code
that
just
did
and
all
comparable
on
its
arguments
taken
as
a
whole?
Yes,
so
that,
and
so
it
lost
its
ordering,
but
would
only
get
the
comparable,
not
arguments,
not
the
passable
arguments.
B
Yeah,
so
that's
I'm,
working
on
something
that
I'm
calling
P
apply
for
now
that
we
would
take
that
to
its
logical
conclusion,
which
is
this:
is
the
exact
opposite
of
the
eventual?
Send
eventual?
Send
you
don't
know
the
destination,
but
you
do
know
the
arguments
well
and
P
apply.
You
do
know
the
destination,
it's
a
function,
but
you
don't
know
the
arguments.
They're
promises
a
bit
of
mixed
kinds
so,
with
the
P
apply,
that
would
return
a
promise
that
you
could
then,
and
basically,
you
can
construct.
B
B
So
what
I'm
thinking
is
on
the
lines
of
there
would
be
these
special
kinds
of
arguments
or
things
that
you
could
pin
bad
in
the
arguments,
and
it's
just
an
apply
of
this
function.
With
these
arguments
and
something
like
P
apply,
callback
would
say
this
means
I
should
do
a
new
promise
and
and
when
I
first
write
file
calls
that
callback.
It
should
resolve
promise.
B
B
B
B
A
A
B
B
B
B
Guess
where
to
say
is
that
the
the
template
here
pays
off,
because
we
have
a
rather
deep
kind
of
nesting
in
our
arguments
and
if
the
promise
was
more
deeply
nested
in
the
arguments
than
that,
the
same
algorithm
is
all
comparable
would
be
able
to
find
it
and
just
do
the
same
as
the
promised
at
all,
which
places
it
back
in
the
same
structure.
So.
A
B
B
B
A
A
So
yeah
there's
always
a
biased.
You
know
towards
the
code
that
one
oneself
has
written
because
one
is
more
familiar
with
it
mm-hmm,
but
so
so
so
so
you
know
I'm
about
to
express
a
preference
for
line
ten
over
line.
Eight
yeah
but
I
want
to
you
know,
take
it
with
a
grain
of
salt
because
of
course,
I
wrote.
All
comparable
yeah
haven't
seen
make
promise
before,
but
I'm
really
I
mean
I'm.
All
comparable
is
a
something
we
also
have.
We
have
for
a
variety
of
reasons
in.
D
B
A
A
And
if
we
sew
with
P,
apply
masu
mning,
assuming
that
we
don't
have
to
worry
about
things
like
the
node
called
adapters
to
the
no
callbacks
tile,
maybe
not
trying
to
solve
that
here.
If
we
see
if
we
assume
away
the
node
callbacks
tile
and
we
had
both
P
apply
and
all
comparable
would
we
need
any
of
the
constants
defined
on
lines,
one
through
five.
B
B
A
So
I
like
this
kind
of
exploration,
we
should
do
more
of
it,
but
in
order
to
avoid
how
much
context
people
need
to
catch
up
on
and
such
I
think
I'm
going
to
go
ahead
and
declare
this
this
meeting
adjourned
mm-hmm-
and
this
was
great-
this
was
we
really.
This
was
a
very
good
exploration.
Okay
thanks.
Everyone
actually.