Mark S. Miller erights at
Wed Nov 14 09:41:28 PST 2012

On Wed, Nov 14, 2012 at 9:25 AM, Kevin Smith <khs4473 at> wrote:

> I think you meant "optimally colored bikeshed," but OK.
> Ouch : )
> Names are important.  Especially when it comes to something as potentially
> confusing as promises and futures.

I agree that names are important.
1) First choice would be to use existing words, where their existing
meanings (whether nat-lang or prior technical use) clearly suggests their
intended technical meaning.
2) Second choice would be to use words whose existing meanings do not
conflict with their intended technical meaning, and where programmers do
not mistakenly assume they know the wrong meaning.
3) Like #2, but coining new words if needed.
4...) anything else is too likely to cause confusion.

In doing the E non-blocking promises, I looked at the history of usage of
the terms "promise" and "future". Several people had tried to use both
terms in order to make a distinction. But historically, I could not find
any consistency. For every interesting distinction, "promise" and "future"
were used by someone on each side of the distinction. However, both were
used primarily for the abstraction of designating a yet-to-be-determined

Historically, the primary examples I can think of[1] of an abstraction that
bundles both the delayed designation and the ability to determine what is
designated is the logic variable (especially in concurrent logic languages)
and the Python Deferred, which inspired various JS Defferds. If you
consider this prior history of Deferreds to be significant, then our
choices of Promise/Resolver/Deferred would be following strategy #1.
Otherwise, Deferred is a new coinage and fits in strategy #3. Either way,
Scala's unfortunate choice clearly violates this history in a confusing
manner, so I'd classify it as #4. Let's not repeat Scala's mistake.

[1] Off the top of my head now, without actually going back to the history.

> - Kevin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list