[boost] [boost.async] new name
Klemens Morgenstern via Boost
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
Richard Hodges via Boost
bo...@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:
>
the positive?
>
> async.core
> await
> co_async / cosync
> co20 / cor20
>
>
Klemens Morgenstern via Boost
<bo...@lists.boost.org> wrote:
>
> On Thu, 12 Oct 2023 at 04:51, Klemens Morgenstern via Boost <
> bo...@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 via Boost
bo...@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 via Boost
Why?
>
> While you didn't ask for it, let me offer some thoughts about the naming rather than a yes/no.
>
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.
>
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.
>
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".
>
> "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.
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 via Boost
klemensdavi...@gmail.com> napisał(a):
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;
Darryl Green via Boost
bo...@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
>
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.
Hadriel Kaplan 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.
-hadriel
Richard Hodges via Boost
bo...@lists.boost.org> wrote:
> > Anything with an underscore in it is an instant no from me.
>
> Why?
>
>
- More hassle to type.
- Doesn't add any information
Andrey Semashev via Boost
> 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
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 via Boost
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 via Boost
- Espen Harlinn
Niall Douglas via Boost
>>> 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.
One reason I like Boost.CO20 is because Google shows absolutely nothing
C++ related for that search.
Niall
Christian Mazakas via Boost
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
Alan de Freitas via Boost
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 <
bo...@lists.boost.org> escreveu:
--
Alan Freitas
https://alandefreitas.github.io/alandefreitas/
<https://github.com/alandefreitas>
Espen Harlinn via Boost
Personally, I don't like acronyms, but prefer meaningful names that I am able to pronounce.
- Espen Harlinn
-----Original Message-----
From: Boost <boost-...@lists.boost.org> On Behalf Of Christian Mazakas via Boost
Sent: Thursday, 12 October 2023 19.25
To: bo...@lists.boost.org
Cc: Christian Mazakas <christia...@gmail.com>
Subject: Re: [boost] [boost.async] new name
Vinícius dos Santos Oliveira via Boost
bo...@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/
Andrzej Krzemienski 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;
Christian Mazakas via Boost
> something funny, like CIA, or the name of your pet.
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 via Boost
bo...@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 via Boost
<bo...@lists.boost.org> wrote:
>
> On Fri, Oct 13, 2023 at 7:34 AM Christian Mazakas via Boost <
> bo...@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 via Boost
klemensdavi...@gmail.com> wrote:
> Emil suggested Coral for CORoutine ALgorithms.
>
Oh wow... "Boost.Coral" - I love this.
Thanks
Christian Mazakas via Boost
- Christian
Peter Dimov via Boost
> Coral is a fantastic name!
Andrzej Krzemienski via Boost
wrote:
> Christian Mazakas wrote:
>
> > Coral is a fantastic name!
>
> Cobalt is better.
>
captivating.
It has to be either of these two!
+1 for the brilliant direction.
Regards,
&rzej;
Ruben Perez via Boost
wrote:
> Christian Mazakas wrote:
>
> > Coral is a fantastic name!
>
> Cobalt is better.
>
Hadriel Kaplan via Boost
From: Boost <boost-...@lists.boost.org> on behalf of Klemens Morgenstern via Boost <bo...@lists.boost.org>
> Emil suggested Coral for CORoutine ALgorithms.
But let's be honest: it stands for "CORoutines Are Lovely", doesn’t it?:)
-hadriel
Andrzej Krzemienski via Boost
wrote:
>
> From: Boost <boost-...@lists.boost.org> on behalf of Klemens
> Morgenstern via Boost <bo...@lists.boost.org>
> > 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;
Alan de Freitas via Boost
> Emil suggested Coral for CORoutine ALgorithms.
>