[boost.async] new name

newer
[Looking for Feedback] - Fairness...

Klemens Morgenstern

12 Oct 2023 12 Oct '23

12:51 a.m.

Given the renaming requirement, I'd like to query the list if there are any objections to any of the following names: async.core await co_async / cosync co20 / cor20 Thanks, Klemens

Show replies by date

Richard Hodges

12 Oct 12 Oct

3:48 a.m.

On Thu, 12 Oct 2023 at 04:51, Klemens Morgenstern via Boost < boost@lists.boost.org> wrote:

...

Given the renaming requirement, I'd like to query the list if there are any objections to any of the following names:

Are we confirming acceptance of the names by not answering, or answering in the positive?

...

async.core await co_async / cosync co20 / cor20

FWIW, of these, cosync seems to me to be the most intuitive.

...

Thanks,

Klemens

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Klemens Morgenstern

4:02 a.m.

On Thu, Oct 12, 2023 at 11:48 AM Richard Hodges via Boost wrote:

...

On Thu, 12 Oct 2023 at 04:51, Klemens Morgenstern via Boost < boost@lists.boost.org> wrote:

...
Given the renaming requirement, I'd like to query the list if there are any objections to any of the following names:

Are we confirming acceptance of the names by not answering, or answering in the positive?

Either is fine, I just need to make sure the names are acceptable at this point. I am also open to serious ideas.

...

...
async.core await co_async / cosync co20 / cor20

FWIW, of these, cosync seems to me to be the most intuitive.

That's good. I fear other people might interpret it as co_... sync, i.e. something that co_awaits synchronous things. Maybe spelled co_sync is worse?

Andrzej Krzemienski

5:04 a.m.

czw., 12 paź 2023 o 02:51 Klemens Morgenstern via Boost < boost@lists.boost.org> napisał(a):

...

Given the renaming requirement, I'd like to query the list if there are any objections to any of the following names:

async.core await co_async / cosync co20 / cor20

While you didn't ask for it, let me offer some thoughts about the naming rather than a yes/no. I understand that your library is a *frontend* for asynchronous computations, rather than a backend. A thing like Boost.ASIO or another executor would be a backend. Is that a correct characterization? If yes, "async.core" sends an opposite message: as if it was a backend. The introductory sentence in GitHub say: This library provides a set of easy to use coroutine primitives & utilities running on top of boost.asio. These will be of interest for applications that perform a lot of IO that want to not block unnecessarily, yet still want to have linear & readable code (i..e. avoid callbacks). One could summarize it even shorter as "a set of awaitables and basic algorithms on them". In this spirit the name "Boost.Awaitables" would reflect this, "await" (as a verb) a bit less so. "co_async" does reflect that it will have something to do with C++ coroutines, but doesn't say what. If you wanted to say "the subset of usages of coroutines that deal with asynchrony", you are losing it. It looks more like "a better version of boost::asio::co_spawn". "cosync" no longer associates with C++ coroutines because of the missing underscore. I read this as "cosine". "co20" is so strange that it could actually do the trick. It would fit into the same category as Boost.Spirit, Boost.Phoenix, Boost.Beast: it's just a cool name, if you want to learn what the library is for go to the documentation. But you might as well go with Boost.Zen. Regards, &rzej;

Klemens Morgenstern

5:26 a.m.

...

Anything with an underscore in it is an instant no from me.

Why?

...

While you didn't ask for it, let me offer some thoughts about the naming rather than a yes/no.

Any help is appreciated. Naming is the second hardest task in software development after all.

...

I understand that your library is a *frontend* for asynchronous computations, rather than a backend. A thing like Boost.ASIO or another executor would be a backend. Is that a correct characterization? If yes, "async.core" sends an opposite message: as if it was a backend.

Well the idea there is that I enthusiastically hope for more libraries using my coros, e.g. async.http. Hence core would be the core library of a bunch of async.* libs. But I guess that is based on high hopes on my end with the additional big question of whether or not people writing those libraries would even want to do that. beast isn't named asio.http either.

...

The introductory sentence in GitHub say:

This library provides a set of easy to use coroutine primitives & utilities running on top of boost.asio. These will be of interest for applications that perform a lot of IO that want to not block unnecessarily, yet still want to have linear & readable code (i..e. avoid callbacks).

One could summarize it even shorter as "a set of awaitables and basic algorithms on them". In this spirit the name "Boost.Awaitables" would reflect this, "await" (as a verb) a bit less so.

Well I don't like awaitable, as it's something that can be awaited. But my lib provides the things that await as well, so it would be boost.awaiters. Which is also weird, hence the idea of `await`.

...

"co_async" does reflect that it will have something to do with C++ coroutines, but doesn't say what. If you wanted to say "the subset of usages of coroutines that deal with asynchrony", you are losing it. It looks more like "a better version of boost::asio::co_spawn". "cosync" no longer associates with C++ coroutines because of the missing underscore. I read this as "cosine".

And co_sync would have the same issues as co_async?

...

"co20" is so strange that it could actually do the trick. It would fit into the same category as Boost.Spirit, Boost.Phoenix, Boost.Beast: it's just a cool name, if you want to learn what the library is for go to the documentation. But you might as well go with Boost.Zen.

Well plus I don't like version numbers in libraries. A few standards down the line, they seem out of date and as if they only were for this version. Now I know better in the case of boost.mp11 for example, but new users might not. But I guess that it's coro with r -> 2, so co2o, isn't as obvious as i hoped.

Andrzej Krzemienski

6:04 a.m.

czw., 12 paź 2023 o 07:26 Klemens Morgenstern < klemensdavidmorgenstern@gmail.com> napisał(a):

...

...
Anything with an underscore in it is an instant no from me.

Why?

...
While you didn't ask for it, let me offer some thoughts about the naming

rather than a yes/no.

...
Any help is appreciated. Naming is the second hardest task in software development after all.

...
I understand that your library is a *frontend* for asynchronous computations, rather than a backend. A thing like Boost.ASIO or another executor would be a backend. Is that a correct characterization? If yes, "async.core" sends an opposite message: as if it was a backend.

Well the idea there is that I enthusiastically hope for more libraries using my coros, e.g. async.http. Hence core would be the core library of a bunch of async.* libs. But I guess that is based on high hopes on my end with the additional big question of whether or not people writing those libraries would even want to do that. beast isn't named asio.http either.

...
The introductory sentence in GitHub say:

This library provides a set of easy to use coroutine primitives & utilities running on top of boost.asio. These will be of interest for applications that perform a lot of IO that want to not block unnecessarily, yet still want to have linear & readable code (i..e. avoid callbacks).

One could summarize it even shorter as "a set of awaitables and basic algorithms on them". In this spirit the name "Boost.Awaitables" would reflect this, "await" (as a verb) a bit less so.

Well I don't like awaitable, as it's something that can be awaited. But my lib provides the things that await as well, so it would be boost.awaiters. Which is also weird, hence the idea of `await`.

I would think "awiatable" is like an iterator: an interface between two parties: one party exposes the interface, the other party consumes the interface. I like the usage of "await" as it sends the message "out of many ways for doing asynchrony, we propose one based on awaitiables". Maybe other grammatical forms of "await" is an option: Boost.Awaits Boost.Awaiting

...

...
"co_async" does reflect that it will have something to do with C++

coroutines, but doesn't say what. If you wanted to say "the subset of usages of coroutines that deal with asynchrony", you are losing it. It looks more like "a better version of boost::asio::co_spawn". "cosync" no longer associates with C++ coroutines because of the missing underscore. I read this as "cosine".

And co_sync would have the same issues as co_async?

I wonder how we get from "async" to "sync". Does co_sync imply "it is no longer 'sync' because it is now 'co_'"? Regards, &rzej;

...

...
"co20" is so strange that it could actually do the trick. It would fit

into the same category as Boost.Spirit, Boost.Phoenix, Boost.Beast: it's just a cool name, if you want to learn what the library is for go to the documentation. But you might as well go with Boost.Zen.

Well plus I don't like version numbers in libraries. A few standards down the line, they seem out of date and as if they only were for this version. Now I know better in the case of boost.mp11 for example, but new users might not. But I guess that it's coro with r -> 2, so co2o, isn't as obvious as i hoped.

Richard Hodges

11:09 a.m.

On Thu, 12 Oct 2023 at 09:27, Klemens Morgenstern via Boost < boost@lists.boost.org> wrote:

...

...
Anything with an underscore in it is an instant no from me.

Why?

- Problematic to enunciate. - More hassle to type. - Doesn't add any information

...

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hadriel Kaplan

10:49 a.m.

From: Boost on behalf of Andrzej Krzemienski via Boost Date: Thursday, October 12, 2023 at 1:05 AM

...

"co20" is so strange that it could actually do the trick. It would fit into the same category as Boost.Spirit, Boost.Phoenix, Boost.Beast: it's just a cool name, if you want to learn what the library is for go to the documentation. But you might as well go with Boost.Zen.

"Boost.CIA" has 28 votes in the reddit thread: https://old.reddit.com/r/cpp/comments/175artw/boostasync_peer_review_report_... -hadriel

Darryl Green

8:35 a.m.

On Thu, 12 Oct 2023, 10:51 am Klemens Morgenstern via Boost, < boost@lists.boost.org> wrote:

...

Given the renaming requirement, I'd like to query the list if there are any objections to any of the following names:

async.core await co_async / cosync co20 / cor20

I've been lurking. I haven't tried the library yet but it looks convenient. As to land grabs, so many words taken. cosync is ugly and co_async is uglier. co20 and cor20 answer a question nobody asked? And the questions that they provoke i.e. is a better cor20 cor20_2 or cor20.1 or cor21 (or std::cor in some future year?) are equally uneceasary. Just cor is punny to me but likely to niche.. await is almost ok but only half of what it does. Maybe boost.responsive is a good name for what it does (and as nobody has a preconceived formal definition of a responder or a um thing to respond to its not a grab) and for how the name was arrived at (if it gets any support!). Half joking at the bikeshed.

Andrey Semashev

12:18 p.m.

On 10/12/23 03:51, Klemens Morgenstern via Boost wrote:

...

Given the renaming requirement, I'd like to query the list if there are any objections to any of the following names:

async.core await co_async / cosync co20 / cor20

I'm not going to pick any name, but will comment on the process of picking itself. While picking a name, consider the alternative spellings that will be used in various places, such as: - In written correspondence such as this mailing list and GitHub issues. Note that there are official guidelines[1] as to how a library should be referenced, which basically boils down to "Boost.LibraryName" or "the LibraryName library". Sometimes people use just "LibraryName" for short, when it is obvious to refer to a Boost library. Note the CamelCase with no spaces. - On Boost website, such as the library list[2] and release notes[3]. There's a variety of approaches taken there, but "Library Name" (i.e. Camel Case with spaces) seems to be the most common, as it is more readable English. - In URLs and filesystem paths. This primarily concerns the GitHub repository name, and is usually spelled as "library_name" (lower-case with underscores). - In code, such as namespace/class/function names, macro name decoration, Boost.Build and CMake target names and so on. For macros, it should be "BOOST_LIBRARY_NAME" (all-caps with underscores, prefixed with "BOOST_"), for others it should be "library_name" (lower-case with underscores). Sometimes there is a clash between the namespace name and a class or function name, in that case the namespace name should be different, but not too much. A few examples are: Boost.Align/boost::alignment/boost::alignment::align(), Boost.Tuple/boost::tuples/boost::tuples::tuple<>. So, a good library name should look good and unambiguous in all these spellings, and preferably easy to type. From this perspective, names using special characters like underscores and dots are more problematic and less preferred. Multi-word is ok, as long as it is easy to unambiguously map to one of the spellings mentioned above, but single-word is better still. Remember that people will be typing the library name in correspondence and code, hopefully for many-many years ahead, and it would be prudent to minimize the risk of spelling errors now. A note about "async.core" and alike. Such naming suggests that "core" is a part of a larger "async" library that must contain some other parts as well. We have a precedent, Boost.Spirit, which contains Qi, Karma, Classic and X3. This also translates to namespace structure (there are boost::spirit::qi, boost::spirit::karma and so on) and macro names. My understanding is that this is not the case with your library, so "async.core" would be confusing and misleading. [1]: https://www.boost.org/community/policy.html#lib_names [2]: https://www.boost.org/doc/libs/1_83_0/ [3]: https://www.boost.org/users/history/version_1_83_0.html

Christian Mazakas

2:08 p.m.

I actually really liked the one suggestion I saw on reddit to call it CIA. Asio became a backronym for the Australian agency so I think CIA is perfect, where CIA = "coroutines in Asio". I think this is the most apt name. Not a huge fan of any of the other suggested alternatives presented in the opening post. - Christian

Espen Harlinn

2:25 p.m.

...

...
I actually really liked the one suggestion I saw on reddit to call it CIA. Try googling that. I think future users of any library would appreciate that a name isn't *very* widely used in another context.

- Espen Harlinn -----Original Message----- From: Boost On Behalf Of Christian Mazakas via Boost Sent: Thursday, 12 October 2023 16.09 To: boost@lists.boost.org Cc: Christian Mazakas Subject: Re: [boost] [boost.async] new name I actually really liked the one suggestion I saw on reddit to call it CIA. Asio became a backronym for the Australian agency so I think CIA is perfect, where CIA = "coroutines in Asio". I think this is the most apt name. Not a huge fan of any of the other suggested alternatives presented in the opening post. - Christian _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Niall Douglas

2:28 p.m.

On 12/10/2023 15:25, Espen Harlinn via Boost wrote:

...

...
...
I actually really liked the one suggestion I saw on reddit to call it CIA. Try googling that. I think future users of any library would appreciate that a name isn't *very* widely used in another context.

Agreed. One reason I like Boost.CO20 is because Google shows absolutely nothing C++ related for that search. Niall

Christian Mazakas

5:25 p.m.

Actually, I just tested "boost C++ CIA" and Google even showed me the literal reddit message that suggested the name. For me, the top result was the boost.org site. Seems like for me at least Google has no issue with it, provided you seed your search query with some relevant helpers. The problem with CO20 is that it doesn't make much sense. At least "coroutines in Asio" describes the library dramatically better and sets user expectations appropriately. Plus, it's a fun little inside joke with Asio and the Australian Security Intelligence Organization. There's ASIO and the CIA and they work perfectly together. - Christian

Espen Harlinn

8:36 p.m.

...

...
There's ASIO and the CIA and they work perfectly together. Clever, but does it turn CIA into a good name for a C++ library?

Personally, I don't like acronyms, but prefer meaningful names that I am able to pronounce. - Espen Harlinn -----Original Message----- From: Boost On Behalf Of Christian Mazakas via Boost Sent: Thursday, 12 October 2023 19.25 To: boost@lists.boost.org Cc: Christian Mazakas Subject: Re: [boost] [boost.async] new name Actually, I just tested "boost C++ CIA" and Google even showed me the literal reddit message that suggested the name. For me, the top result was the boost.org site. Seems like for me at least Google has no issue with it, provided you seed your search query with some relevant helpers. The problem with CO20 is that it doesn't make much sense. At least "coroutines in Asio" describes the library dramatically better and sets user expectations appropriately. Plus, it's a fun little inside joke with Asio and the Australian Security Intelligence Organization. There's ASIO and the CIA and they work perfectly together. - Christian _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Alan de Freitas

7:19 p.m.

I like the idea of some variant of "await" because it's intriguing enough to get people to read the docs. "await" represents only half the library, but the word that represents both halves, like it or not, is "coroutines". There are also more than these two coroutine halves in the library because of its extensions. I'm also OK with some fun names like "CIA" because it implicitly represents there can be more things included in the library. About the ones I don't like: - async.core (i) carries the same problem as the original name and (ii) makes it more confusing because now there's "core" but no "not-core" as it is. If X is everything (as it is), then X cannot be the "core" of itself. - co_async / co_sync (i) include a special character, (ii) still carry "async", and (iii) the alternatives suggests it could also be "sync". But if something is "A || !A", then A discriminates nothing in the context and it probably shouldn't be described in these terms. It has no cognitive significance. - co20 (i) is going to look outdated soon and (ii) doesn't represent the library better than Boost.Co or Boost.Coroutines (if it didn't exist). About (i), people will be talking about C++26 next year already. The name means co>=20 but people will instantly have the intuition of co=20 and feel like we're past that. About (ii), there's no intentionality in "20" in terms of library design. It's just something that happens to be true. Em qua., 11 de out. de 2023 às 21:51, Klemens Morgenstern via Boost < boost@lists.boost.org> escreveu:

...

Given the renaming requirement, I'd like to query the list if there are any objections to any of the following names:

async.core await co_async / cosync co20 / cor20

Thanks,

Klemens

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- Alan Freitas https://alandefreitas.github.io/alandefreitas/ https://github.com/alandefreitas

Andrzej Krzemienski

13 Oct 13 Oct

7 a.m.

czw., 12 paź 2023 o 21:20 Alan de Freitas via Boost napisał(a):

...

I like the idea of some variant of "await" because it's intriguing enough to get people to read the docs.

Agreed.

...

"await" represents only half the library, but the word that represents both halves, like it or not, is "coroutines". There are also more than these two coroutine halves in the library because of its extensions.

This is where I believe the documentation of the library does not do a good job of explaining to non-experts what are its goals and when it should be used. If we had that information, the choice of the name would be easier. I built the following understanding of the library during the course of the two reviews: 1. It is a triplet: (1) awaitable interface/concept, (2) coroutine-return-types compatible with the interface that help you build your coroutines, (3) algorithms on the awaitables. It is similar to the triplet "containers, iterators, algorithms in STL", where the iterators were the real invention -- that is the interface. 2. The motto of the library is, "if you are planning to write your asynchronous app, consider using this library, it will make your life easier". 3. Out of many possible coroutine-return types, we offer only the ones that are themselves awaitables: nothing like std::generator. So the name should be either something that reflects this, or just something funny, like CIA, or the name of your pet. Regards, &rzej; I'm also OK with some fun names like "CIA" because it implicitly represents

...

there can be more things included in the library.

About the ones I don't like:

- async.core (i) carries the same problem as the original name and (ii) makes it more confusing because now there's "core" but no "not-core" as it is. If X is everything (as it is), then X cannot be the "core" of itself. - co_async / co_sync (i) include a special character, (ii) still carry "async", and (iii) the alternatives suggests it could also be "sync". But if something is "A || !A", then A discriminates nothing in the context and it probably shouldn't be described in these terms. It has no cognitive significance. - co20 (i) is going to look outdated soon and (ii) doesn't represent the library better than Boost.Co or Boost.Coroutines (if it didn't exist). About (i), people will be talking about C++26 next year already. The name means co>=20 but people will instantly have the intuition of co=20 and feel like we're past that. About (ii), there's no intentionality in "20" in terms of library design. It's just something that happens to be true.

Em qua., 11 de out. de 2023 às 21:51, Klemens Morgenstern via Boost < boost@lists.boost.org> escreveu:

...
Given the renaming requirement, I'd like to query the list if there are any objections to any of the following names:

async.core await co_async / cosync co20 / cor20

Thanks,

Klemens

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- Alan Freitas https://alandefreitas.github.io/alandefreitas/ https://github.com/alandefreitas

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Christian Mazakas

2:34 p.m.

...

So the name should be either something that reflects this, or just something funny, like CIA, or the name of your pet.

Agreed. There's no need to tie the name to something async-y. Several Boost libraries have whimsical names and they're great. There's Yap, Spirit, Phoenix, Beast, etc. Perhaps we should pivot and avoid trying to cram "co_" or "await" or "async" in there. - Christian

Vinnie Falco

2:51 p.m.

On Fri, Oct 13, 2023 at 7:34 AM Christian Mazakas via Boost < boost@lists.boost.org> wrote:

...

Agreed. There's no need to tie the name to something async-y. Several Boost libraries have whimsical names and they're great.

I missed my chance: Boost.Earl Thanks

Klemens Morgenstern

4:07 p.m.

On Fri, Oct 13, 2023 at 10:51 PM Vinnie Falco via Boost wrote:

...

On Fri, Oct 13, 2023 at 7:34 AM Christian Mazakas via Boost < boost@lists.boost.org> wrote:

...
Agreed. There's no need to tie the name to something async-y. Several Boost libraries have whimsical names and they're great.

If they're an acronym at the same time you've gone full gnu. Emil suggested Coral for CORoutine ALgorithms. I am currently considering going with cobalt, COroutines Basic ALgorithms & Types.

...

I missed my chance: Boost.Earl

If we're doing nobility, it should be Boost.Count, so it starts with "co".

Vinnie Falco

4:08 p.m.

On Fri, Oct 13, 2023 at 9:07 AM Klemens Morgenstern < klemensdavidmorgenstern@gmail.com> wrote:

...

Emil suggested Coral for CORoutine ALgorithms.

Oh wow... "Boost.Coral" - I love this. Thanks

Christian Mazakas

4:59 p.m.

Coral is a fantastic name! - Christian

Peter Dimov

5:29 p.m.

Christian Mazakas wrote:

...

Coral is a fantastic name!

Cobalt is better.

Andrzej Krzemienski

5:34 p.m.

On Fri, Oct 13, 2023, 19:30 Peter Dimov via Boost wrote:

...

Christian Mazakas wrote:

...
Coral is a fantastic name!

Cobalt is better.

Cobalt is more accurate but coral is so attractively simple and captivating. It has to be either of these two! +1 for the brilliant direction. Regards, &rzej;

...

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Ruben Perez

5:35 p.m.

On Fri, 13 Oct 2023, 19:30 Peter Dimov via Boost, wrote:

...

Christian Mazakas wrote:

...
Coral is a fantastic name!

Cobalt is better.

Hadriel Kaplan

5:41 p.m.

From: Boost on behalf of Klemens Morgenstern via Boost

...

Emil suggested Coral for CORoutine ALgorithms. Boost.Coral is pretty good! But let's be honest: it stands for "CORoutines Are Lovely", doesn’t it?:) -hadriel

Andrzej Krzemienski

6:39 p.m.

On Fri, Oct 13, 2023, 19:41 Hadriel Kaplan via Boost wrote:

...

From: Boost on behalf of Klemens Morgenstern via Boost

...
Emil suggested Coral for CORoutine ALgorithms. Boost.Coral is pretty good! But let's be honest: it stands for "CORoutines Are Lovely", doesn’t it?:)

COmunity-Reviewed Async Library. &rzej; -hadriel

...

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Alan de Freitas

7:46 p.m.

...

Emil suggested Coral for CORoutine ALgorithms.

That sounds amazing.

Vinícius dos Santos Oliveira

12 Oct 12 Oct

8:57 p.m.

Em qui., 12 de out. de 2023 às 00:51, Klemens Morgenstern via Boost < boost@lists.boost.org> escreveu:

...

Given the renaming requirement, I'd like to query the list if there are any objections to any of the following names:

async.core

I don't have any strong objections. await

...

I like this option. co_async / cosync

...

These names are terrible. You have yet to explain what a synchronous coroutine is. If there are "asynchronous" coroutines, then there are synchronous ones too I suppose. co20 / cor20

...

I don't have any objection to these options. These last options do remind me of chemistry though. Don't want to name the library as "carbon" or something? Feel free to ignore this idea. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

410

Age (days ago)

411

Last active (days ago)

List overview

Download

28 comments

14 participants

participants (14)

Alan de Freitas
Andrey Semashev
Andrzej Krzemienski
Christian Mazakas
Darryl Green
Espen Harlinn
Hadriel Kaplan
Klemens Morgenstern
Niall Douglas
Peter Dimov
Richard Hodges
Ruben Perez
Vinnie Falco
Vinícius dos Santos Oliveira