Where'd Promise#done go?

Mark S. Miller erights at google.com
Thu Jun 20 08:55:18 PDT 2013


On Thu, Jun 20, 2013 at 7:50 AM, David Bruant <bruant.d at gmail.com> wrote:

>  Le 20/06/2013 14:55, Forbes Lindesay a écrit :
>
>  I’ve been answering quite a few questions about promises on stack
> overflow lately.
>
> Do you have a link to a list to these questions (and/or your answers)
> off-top your browser history by any chance?
>
>
>  One of the key things people seem to struggle to get their head around
> is the idea of `.then` as being something that transforms the promise and
> returns a new promise.  They either expect it to mutate the existing
> promise or they expect it to behave like `.done()` does.
>
> I wasn't there when that started,
>

I was ;)


> but it feels like "then" organically grew out of the experience of using
> promises a lot which naturally leads to promise pipelining.
> It doesn't feel like the most "fundamental brick" to understand what
> promises are (what .done looks like though), because it isn't.
> At a first approximation, people can use .then the way the expect (without
> caring for the return value)
>

.then comes directly from E's "when", which comes from Original-E's "when",
which comes from experience with Joule. See Concurrency Among Strangers <
http://www.erights.org/talks/promises/paper/tgc05.pdf> or the expanded and
updated version in Part 3 and Chapter 23 of <
http://erights.org/talks/thesis/markm-thesis.pdf>. For the history
especially, see that Chapter 23 -- "From Objects to Actors and Back Again".

I'm always surprised when people think that any of these callback forms are
the fundamental starting point. The fundamental starting point is the
asynchronous message send, expressed in E as infix "<-", in Q as .send, and
proposed for ES7 as infix "!". In both E and Joule, .then-like callbacks
were built as a pattern on top of message sending.

On the particular issue in question, the return value of .then,
historically you are correct. Original-E and early E had a "when" that did
not return a promise for the result. That idea was contributed by Mark
Seaborn on the e-lang list, I believe sometime in the late '90s, but I
haven't yet found the crucial message in the archive <
http://www.eros-os.org/pipermail/e-lang/>.

This change made a fundamental difference in the style of using "when".
Without the return result, the only purpose of "when" is the side-effects
performed by the callbacks, which necessarily takes you out of functional
thinking into imperative thinking. With the return result, "when" is still
potentially functional. As with lazy evaluation, when used functionally,
both asynchronous message sending and "when" are just ways
of rearranging the time of functional computation.

So the question about the order of teaching of .done vs .then depends on
the overall teaching strategy. Some teaching strategies, such as SICP and
CTM, teach functional first and only get to imperative constructs rather
late. Prior to imperative constructs, .done makes sense only for its error
reporting, when capping a promise sequence -- which, after all, was the
reason for introducing .done in the first place. For this purpose, I
recommend teaching only the parameterless form: p.done(); But I do
recommend teaching it, as dropping errors silently is especially harmful to
someone first learning a new programming paradigm.



>
>  ****
>
> ** **
>
> I think `.done()` could be extremely useful purely as a teaching device.
> If we started everyone off by learning to use `.done()` they would have a
> much shallower learning curve.  Initially they’d get all their errors
> thrown immediately which would be easier to see.
>
> That's how Q behaves out of necessity, but native promises can have better
> integration with debugging tools and don't need to reflect the error at
> runtime.
>
>
>  It would be much more similar to typical (but terrible) DOM APIs and
> jQuery APIs that are event based or have a callback and an errback.  Having
> learnt to use `.done()` we could teach `.then()` as a more advanced feature
> that let you compose asynchronous operations by returning a promise that
> has been transformed by the callbacks.
>
> .then can be taught without telling it returns something ;-)
>
> David
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130620/bd05cf98/attachment.html>


More information about the es-discuss mailing list