Herby Vojčík herby at
Fri Nov 16 06:26:40 PST 2012

Mark S. Miller wrote:
> On Wed, Nov 14, 2012 at 9:25 AM, Kevin Smith <khs4473 at
> <mailto: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.

When I see hardships around existing proposal, I go for something crazy. 
So #4 prbably according to above terminology.

I would use .notyet (or .notYet) instead of .future for the end.

Promise for the beginning seems fine (at least, there is only one of the 
promise/future pair), but I can as well see "Will" or "Shall" there.

let foo = Will(...);
let bar = foo.notyet;

and later some matching API, like



> 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 value.
> 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
> --
>      Cheers,
>      --MarkM
> ------------------------------------------------------------------------
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list