rename "promise" to "future" (or "fncall"?)

[andrewrk]

Somebody suggested this and I think it might make sense.

Right now when you make an async function call, you get a promise->T. You can implicitly cast promise->T to promise.

• await works on promise->T
• resume and cancel works on promise
• suspend gives you a promise->T

It's kind of weird to "resume a promise" and "cancel a promise". It makes a little more sense to "resume a future" and "cancel a future".

This proposal is to change "promise" to "future". Another contender might be "coro" (short for coroutine). Another idea that I just made up is "fncall". It makes a lot of sense to "resume a fncall", "cancel a fncall", "suspend a fncall", and nobody is going to use fncall as an identifier.

[sebastien]

If I might add to the discussion, I would make the following distinction:

• A coroutine is essentially a new line in the control flow (such as processes, thread and fibers/green threads/lightweight threads/coroutines), meaning it abstracts away a process, not necessarily a value (think of a coroutine that just sleeps for 10s). As a result, it's not the best use of the term to denote values (which promises and future do)

• A functional call is an operation, which operational semantics can greatly vary. In most runtimes, a functional call means the current control flow is borrowed from the call site. This control flow is also a line in the overall control flow (ie. a process, thread, etc). In using the term fncall you would then be referring to an operation that, as a side effect, does something to the control flow, but not necessarily to its result.

So I would say that coroutines (as coro) and function calls (as fncall) would be pertinent as denotations of different types of control flow lines (such as processes and threads) -- hence the cancel/resume/suspend, but do not really denote the same things as promises or futures, which are resulting values that might not have exist/been evaluated yet.

To sum this up, control flow is the means/process that allows for the production of the value, and is more appropriate to denote the sequence of actions than the result.

There's a Wikipedia page about Futures and Promises which I hadn't read before, which contains a lot of references. I'm not sure what the introduction is worth though as the only reference for futures comes from Scala, which is definitely not a historical pioneer for the term.

[sebastien]

If I might add to the discussion, I would make the following distinction:

• A coroutine is essentially a new line in the control flow (such as processes, thread and fibers/green threads/lightweight threads/coroutines), meaning it abstracts away a process, not necessarily a value (think of a coroutine that just sleeps for 10s). As a result, it's not the best use of the term to denote values (which promises and future do)

• A functional call is an operation, which operational semantics can greatly vary. In most runtimes, a functional call means the current control flow is borrowed from the call site. This control flow is also a line in the overall control flow (ie. a process, thread, etc). In using the term fncall you would then be referring to an operation that, as a side effect, does something to the control flow, but not necessarily to its result.

So I would say that coroutines (as coro) and function calls (as fncall) would be pertinent as denotations of different types of control flow lines (such as processes and threads) -- hence the cancel/resume/suspend, but do not really denote the same things as promises or futures, which are resulting values that might not have exist/been evaluated yet.

To sum this up, control flow is the means/process that allows for the production of the value, and is more appropriate to denote the sequence of actions than the result.

There's a Wikipedia page about Futures and Promises which I hadn't read before, which contains a lot of references. I'm not sure what the introduction is worth though as the only reference for futures comes from Scala, which is definitely not a historical pioneer for the term.

[sophistifunk]

Just my 2c, I think ideally you'd want separate entities for the promise (a future result) and the task (resume and cancel).

Also might be nice to take into account some future design for streams, just so the semantics of a stream-that-only-yields-once looks / behaves much like a promise+task combination

EDIT: All these damned words are so overloaded 😂😭

[sophistifunk]

Just my 2c, I think ideally you'd want separate entities for the promise (a future result) and the task (resume and cancel).

Also might be nice to take into account some future design for streams, just so the semantics of a stream-that-only-yields-once looks / behaves much like a promise+task combination

EDIT: All these damned words are so overloaded 😂😭

[sebastien]

+1 for the streams -- they're similar to futures but can have multiple different values. Iterators are conceptually similar but usually don't have an abstraction that share traits with future, while they probably should.

[sebastien]

+1 for the streams -- they're similar to futures but can have multiple different values. Iterators are conceptually similar but usually don't have an abstraction that share traits with future, while they probably should.