{#design}: Find better words for the two meanings of "algorithm" about stdexec

[mjgarland]

Sender consumers? That would fit with your definition of the third category, since you specifically used the word "consume".

[LeeHowes]

Do we have equivalents of these names in the ranges space? We should try to be consistent with that.

[villevoutilainen]

What things are we talking about here for the third category? sync_wait? If we have a bunch of examples of these sender launchers, we might have a better chance of coming up with a name for them.

[lewissbaker]

Do we have equivalents of these names in the ranges space?

In ranges these terminal operations are called "actions" - maybe we can reuse this term for senders?

If we have a bunch of examples of these sender launchers, we might have a better chance of coming up with a name for them.

Some examples I can think of:

• sync_wait(sender)
• async_scope::spawn(sender) - connect/start the operation which can be later joined using the async_scope object
• submit(sender, receiver)

Other categories of function for a sender might be things that translate a sender into a different category of things:

• something that adapts a sender into a hypothetical async_range.
  e.g. async_range single(sender auto s) or async_range repeat(sender auto s)
• something that adapts a sender into a std::future
  e.g. auto to_future(sender auto s) -> std::future<sender_single_value_t<delctype(s)>>

Would both of these also be "actions"?

Or that adapt other categories of things into senders:

• something that takes a hypothetical async_range and returns a sender.
  e.g. sender first(async_range auto src) or sender reduce(async_range auto src, auto initialState, auto reduction)

Would these be "sender factories"?

A "sender adapter" to me is something that I can curry other parameters into and produce a callable that takes as input a sender and returns a sender. An adapter has a kind of "primary" input sender that it operates on even if it also accepts other senders. Adapters are the kinds of things that generally fit well into a pipeable syntax.

I'm not sure that the when_all() algorithm would fall into the "sender adapter" categorisation as it doesn't really have a "primary sender", though. Whereas an algorithm like stop_when(sender auto src, sender auto trigger) would fall into this categorisation as the src can be thought of as the primary input and the trigger as an additional parameter.

I tend to think of the overarching umbrella of functions that operate on senders for which there is a default implementation as all being collectively called "sender algorithms".

Customisable functions for which there is no default implementation I have been calling "basis functions", possibly prefixed with the concept name for which these basis functions generally apply to.

[mjgarland]

Is "consuming" the sender in some fashion an important characteristic of the operations in this third category that needs a name? Would we consider pure query functions like get_completion_scheduler to be in or out of this category?

[lewissbaker]

Is "consuming" the sender in some fashion an important characteristic of the operations in this third category that needs a name? Would we consider pure query functions like get_completion_scheduler to be in or out of this category?

Yes, I think I would like to have terminology that distinguishes between queries on a sender and something that consumes/launches that sender.

[brycelelbach]

My suggestion:

"Sink" as the name for things that take senders but don't return them.
"Operation" as the collective name for sender factories, adaptors, and sinks.

[brycelelbach]

@griwes points out that "operation" already has a broader meaning that encompasses queries, like get_completion_scheduler as well. get_completion_scheduler is not what we currently call a "sender algorithm" because it never consumes the input.

It may be fine to have one term for all four of these things, so "operation" may be okay. We can't think of a time when accidentally including the queries would be a problem.

[brycelelbach]

Upon further discussion, we decided that we should just call get_completion_scheduler a query, and use "operation" for "sender factory, sender adapter, or sender thing-that-takes-senders-but-doesnt-return-one".

[brycelelbach]

@griwes suggests "sender consumer" instead of "sender sink". That seems fine to me.

[brycelelbach]

"query": Function-like thing (usually a CPO) but doesn't modify its subject.
"operation": Function-like thing (usually a CPO)
"sender operation": one of "sender factory", "sender adapter", "sender consumer".
"sender factory": Doesn't take any senders, returns a sender.
"sender adapter": Takes senders, returns a sender that depends on them.
"sender consumer": Takes senders and connects to it.

[brycelelbach]

See #85

[brycelelbach]

@lewissbaker points out that "operation" is already used to refer to the thing that a sender does, e..g operation_state. We'll need another word for this.

[brycelelbach]

I think the best option for the time being is to keep "sender algorithm" (the term referring to "sender factory", "sender adapter", and "sender consumer") and rename the second meaning of "sender algorithm" to "sender consumer".

So:

"query": Function-like thing (usually a CPO) but doesn't modify its subject.
"algorithm": Function-like thing (usually a CPO)
"sender algorithm": one of "sender factory", "sender adapter", "sender consumer".
"sender factory": Doesn't take any senders, returns a sender.
"sender adapter": Takes senders, returns a sender that depends on them.
"sender consumer": Takes senders and connects to it.

"Algorithm" is still a problem, because it has a dual meaning - there's also the sequence algorithms in <algorithm>. It may be fine, though, if we judiciously distinguish between "sender algorithms" and "sequence" algorithms.

[brycelelbach]

Long term, I wonder if we can rename "operation state" to something else.