►
From YouTube: Update on Promise Pipelining
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
An
update
on
promised
pipelining.
This
is
an
update
about
a
pair
of
proposals,
both
of
which
were
presented
last
time.
The
eventual
send
proposal,
which
is
the
underlying
API
and
semantics
for
supporting
promise
pipelining
for
supporting
the
ability
to
do
efficient,
distributed
object,
programming,
efficient
and
pleasant,
distributed,
object,
programming
and
the
separate
way,
V
dot
sin
tax
proposal
for
providing
syntactic
support
for
doing
that
kind
of
programming,
and
this
is
an
update
on
both
of
those.
But
we
should
remember
that
they
are
two
separate
proposals.
A
What
we
proposed
last
time
was
that
the
eventual
operations
were
these
five
operations
and
eventual
get
an
eventual
set.
An
eventual
property
assignment
and
eventual
property
delete,
an
eventual
apply
function
and
an
eventual
apply
method,
and
we
came
up
with
this
set
by
starting
with
the
with
the
set
that
we
found
to
be
useful
in
practice
that
we
that
we
ourselves
used
and
then
generalizing
according
to
sort
of
what
the
natural
operations
were
on
property
access
in
JavaScript.
A
However,
having
added
the
having
expanded
the
set
of
operations
to
these
five,
which
we
thought
was
sort
of
the
natural
general
generalization
SoLoMo
tall
on
the
SES
calls
identified
H
what
we
call
the
chained
assignment
anomaly,
which
is,
when
you
see
an
expression
like
that
and
you
just
think
of
wavy
dot
as
adjective
dot.
In
the
same
way,
the
question
mark
dot
is
thought
of,
as
adjective
dot
for
different
adjectives
and
you're.
A
A
Eight
is
eventually
assigning
two
peace
fulfillment
assigning
to
its
food
property,
the
value
eight.
The
problem
is
that
this
expression
as
a
whole,
the
value
of
that
which
is
reified
in
the
code
here
in
the
rewrite
as
t2.
That
value
is
immediately
a
promise
for
what
the
value
of
the
assignment
will
be.
In
other
words,
it's
an
it's
immediately,
a
promise
that
will
eventually
both
be
fulfilled
with
eight
and
then
the
outer
assignment.
A
So
the
result
is
that
there
is
a
violation
of
programmer
expectation
which
you
can
understand
in
terms
of
the
rewrite
or
to
put
it
in
terms
in
which
the
programmer,
using
the
eventual
send
operators
directly
would
be
thinking
when
they're,
not
thinking
about
the
rewrite
they
have.
This
expectation
P,
but
but
P
tilde
phoo,
is
eventually
eight,
whereas
q
till
dot
bar
is
eventually
set
to
a
promise
right.
So
in
the
call
we
started
talking
about
all
sorts
of
ways
to
repair
this,
and
we
realized
wait.
A
A
A
Then
all
you've
got
to
the
remote
object
is
the
ability
to
query
it
or
the
ability
to
ask
it
to
do
something,
and
then
any
state
updates
it
does
are,
according
to
the
semantics
of
its
API,
rather
than
then
expressing
side-effects
to
its
state
remotely
sorry
yeah,
so
the
tilde,
the
P
tilde
foo,
the
P
tell
dot
the
apply.
Basically,
the
eventual
get
the
eventual
apply
function
and
the
eventual
apply
method
is
the
three
that
we're
keeping.
Oh,
oh
I'm.
Sorry,
you
are
correct.
A
I
was
miss
reading
the
slide
because
one
of
them
doesn't
have
syntax.
So
we
also
added
a
has
operation.
So
there's
eventual
has
eventual
set.
An
eventual
delete,
eventual
has
is,
is
still
query
only
someone
could
imagine
keeping
it,
but
it's
really
not
tremendously
useful,
and
what
we're
actually
using
in
practice
is
really
just
these
three.
It's
the
only
thing
that
we've
ever
used
in
practice
going
back
to
the
late
90s,
in
fact,
with
the
earlier
versions
of
this
kind
of
distributed,
promise
computation.
A
We
also
have
another
three,
which
are
the
send
only
variants
of
those
three
and
syntactically
when
the
expression,
the
tell
dot
expression,
appears
in
a
syntactic
context,
like
a
like
the
top
expression
of
an
expression
statement
where
the
value
that
it
returns.
The
promise
that
this
word
return
is
obviously
ignored.
When
mapping
this
into
a
distributed
protocol,
it's
useful
to
know
that,
because
there's
a
ton
of
extra
bookkeeping,
it
enables
you
to
avoid.
A
A
The
void
opera,
the
unary
void
operator
in
JavaScript-
for
those
who
don't
know,
is
one
that
throws
away
the
the
value
of
its
operand
evaluates
the
the
operand
expression
throws
away
the
value
and
the
void
expression
as
a
whole,
just
evaluates
to
undefined
and
frankly,
even
this
one
is
very
suspect,
so
I
colored
this
pink,
rather
than
wiping
it
out
with
red,
but
but
going
forward.
We
should
be
suspicious
that
anytime,
you
see
this.
It's
probably
a
mistake,
because
to
do
a
property
get
only
for
effect
is
unlikely
to
be
what
the
programmer
expected.
A
A
In
the
in
the
remainder
of
its
update,
I
want
to
emphasize
the
symmetry
between
the
way,
we're
thinking
of
handled
promises
and
the
philosophy
that
we
pursued
in
creating
proxies,
because
it
turns
out
that
they're
extremely
parallel.
So
right
now
in
the
language,
we
have
a
new
proxy
API
in
which
in
which
a
proxy
creates
something
that
acts
like
an
object.
But
the
handler
is
the
extension
point
for
reflectively
turning
object
operations
into
traps
on
the
handler.
A
A
So
the
the
the
updated
handled
promise
api
is
as
follows,
which
is
in
the
same
way
that
the
promise
takes
an
argument
function
which
is
called
back,
providing
a
resolve
and
reject
function
for
resolving
the
return
promise
over
here.
The
handle
promise
takes
in
a
function
to
be
called
back,
but
also
takes
in
at
the
bottom
here
this
additional
optional
argument,
which
is
the
unfulfilled
handler
that
will
handle
these
operations
on
an
unknown
on
an
unresolved
handled
promise
and
the
arguments
to
the
callback
function.
A
Resolved
with
presence,
you
provide
a
presence
handler,
which
is
the
thing
that
that
that
enabled
that
says
this
promise
is
now
fulfilled
to
a
remote
object,
but
now
I
still
need
a
handler,
so
that
met
so
that
eventual
operations
on
the
local
promise
can
still
be
serialized
and
sent
to
the
remote
to
the
remote
object.
You
need
to
know
that
it's
resolved
because
a
dot
then
on
a
handled
promise,
while
it's
unresolved,
the
dot,
then
doesn't
fire
when
the
handler
promise
gets
resolved
to
a
remote
object.
A
A
A
A
That
represents
what
the
promise
was
fulfilled
with,
but
what
the
promise
was
actually
fulfilled
with
is
elsewhere
on
the
network.
So
you
can't
provide
the
local
success
callback
with
that
object,
so
we
introduced
this
concept
of
a
presence.
This
goes
back
to
chips,
Unum
model
from
the
90s,
and
the
presence
is
basically
just
a
local
object.
That's
the
local
representative
of
the
actual
remote
object,
but
it
gives
you
the
thing
as
the
callback
and
then
the
tell
dot
applied
to
the
presence
is
equivalent
to
the
tell
dot
applied
to
the
promise
for
the
presence.
A
So
when
we
specified
proxies,
it
turns
out
that
there
is
a
shocking
number
of
elements
to
introducing
proxies
into
the
language
that
you
have
to
get
right
and
you
have
to
make
coherent
with
each
other.
All
of
the
rows
on
this
table
were
elements
of
introducing
proxies
language
correctly,
and
we
got
this
right
and
we
find
that
this
is
a
guiding
parallel
for
understanding
all
of
the
elements
of
handle
promises.
A
A
For
each
of
these
internal
methods
on
objects,
we
gave
it
a
default
behavior
what
what
it
does
on
a
normal
Monica's
otic
object,
and
likewise
for
each
of
these
internal
methods
that
we're
adding
to
all
promises,
we're
giving
it
a
standard
default
behavior
which
is
it
just
turns
into
the
corresponding
eventual
property
access.
So,
even
if
you're
not
concerned
with
remote,
it
gives
you
a
nice
Pleasant
way
to
do
all
these
remote.
Oh,
these
eventual
operations
on
the
phone,
the
fulfillment
of
promises
you've
got
for.
A
A
The
key
new
invariant
is
that
all
of
these
eventual
operations
protect
the
caller
from
reentrant
attacks
that,
if
you
that
for
any
of
these
eventual
operations,
a
code
that
expresses
such
an
operation,
the
operands
of
the
operation
cannot
cause
code
of
their
choosing
to
run
during
the
evaluation
of
that
expression
or
even
during
the
turn
from
which
the
expression
was
out
was
was
evaluated.
That
everything
that
is
caused
by
the
operands
of
the
eventual
operator
are
all
postponed
to
a
later
turn
and
potentially
postponed.
A
You
know
also
something
remote
and
then,
besides,
writing
down
the
invariants.
Since
the
handlers
of
proxies
are
untrusted,
we
have
to
introduce
mechanisms
to
enforce
that
a
malicious
handler
can
still
not
create
a
proxy
that
violates
the
invariants.
Similarly,
we
do
that
with
the
relationship
between
a
handled
promise
and
its
handler,
in
particular,
postponing
the
invocation
of
the
Handler
trap
until
a
later
turn.
A
And
finally,
rather
than
forcing
everybody
using
a
proxy
to
write
all
of
the
handlers
manually,
they
can
omit
some
of
the
high-level
handlers
and
if
they
emit
a
high-level
handler,
it
defaults
to
behavior
in
terms
of
a
low-level
hammer.
So,
for
example,
if
a
handler
implements
get
on
properties
does
not
implement
get,
then
the
proxy
mechanism
provides
a
get
defined
in
terms
of
the
get
on
property
it.
A
It
basically
delegate
slow
a
little
behavior
to
get
on
property
so
that
you
can
just
override
get
on
property
and
you
get
a
consistent
get
behavior
simply
as
a
consequence.
Likewise,
for
all
the
send
onlys,
if
they're
omitted
from
the
handler,
they
just
caused
the
corresponding,
send
a
trap,
throwing
away
the
result
in
returning
undefined
and
the
eventual
method
send.
A
Could
you
can
actually
omit
that
from
the
handler
and
it's
the
equivalent
of
an
eventual
property
get
which
returns
a
promise
for
a
remote
function,
followed
by
an
eventual
invocation
on
the
promise
of
the
remote
function?
To
eventually
invoke
the
remote
function
in
the
case
of
a
distributed
protocol,
the
one
at
the
Forum
on
the
right
is
substantially
more
expensive,
which,
but
but
its
semantics.
Preserving
so
it's
nice
to
have
that
as
a
fallback
and.
A
So
what
we've
not
only
explored
but
actually
implemented
and
providing
in
production,
is
a
proxy
based
shorthand
that
corresponds
the
different
syntactic
shorthand,
but
we
found
we
that
the
path
of
least
resistance
was
basically
to
introduce
three
new
prot
three
new
kinds
of
proxy.
You
need
at
least
two.
You
cannot
do
it
with
one
new
kind
of
proxy,
because
so
this
is
the
event
ship.
So
we
you
know.
Basically
we
have
this
e,
that's
important
for
Martian
and
then
e
dot.
A
G
is
for
an
eventual
getter
that
you
just
say:
dot
get
dot
foo
it
does
the
eventual
get
a
foo
returns
to
you,
a
promise
for
the
result.
F
is
eventual
function,
call
and
then
e
by
itself.
We
use
the
short
form
here,
because
it's
by
far
the
most
common
operation
and
doing
distributed
object
programming
does
the
distributed
method
call,
but
even
that's
bill
leaves
aside
the
only
operation
so
for
each
of
these,
if
you
do
a
dot,
send
only
and
then
do
the
rest
of
it.
A
Then
it
does
the
send
only
variant
throwing
away
the
result
and
avoiding
the
internal
bookkeeping
by
expanding
to
these
internal
methods.
I
mean
these
static
methods
and
I
want
to
use
a
slide
to
emphasize
that
the
important
difference
between
the
right
column
and
the
left
column
is
not
brevity.
It's
not
that
we're
continuing
to
hope
for
the
syntax,
because
it's
smaller
we're
continuing
to
hope
for
the
syntax,
because
it's
much
easier
to
remember
and
understand
that
that
we
leave
it
up
to
the
rewriter
to
look
at
the
expression
and
figure
out
which
of
these
things.