Some channel functions have problematic names

[ivan-cukic]

The functions like zip, join and similar in this library have different meanings compared to some other C++ and non-C++ libraries that model similar or same concepts.

This issue is based on the presentation from Meeting C++ 2017, I haven't checked whether the implementation follows what was presented there.

These are naming collisions against Eric's range-v3 library since those names will become a part of STL at some point, and having the functions with the same names and completely different meanings will be problematic for this library:

• zip should create pairs (tuples) of values from the source channels, not interleave them (round robin)
• join flattens out range of ranges in range-v3 (joining is a usual term for flattening out nested monads) - here, the equivalent would be to have a channel<channel<T>> and to get a channel<T>

Proposal:

• change zip to create pairs/tuples
• make a join function that flattens out nested channels, or remove join function from the library
• merge should accept the merging strategy as an argument - should it be round-robin or unordered (emit whichever value comes first regardless of the source channel) - instead of having to invent different names for all different functions that perform merging and forcing the user to check out the documentation to know which one does what.

p.s. I don't usually comment on APIs (backwards-compatibility and all), but Sean told me the API is not yet considered stable and that there is time for the things to get fixed.

[FelixPetriconi]

I see your point and we will discuss possible changes for the 1.2 release.

[FelixPetriconi]

Sorry, that I just come now back to this.
So zip should be doing, what join is doing now? So it collects a set of n values from all upstream senders and passes it then to the process, that accepts n parameters? Or do you think, that this process should accept a tuple of n elements?
For the beginning, I would not implement a reduction/join.
So merge then will be parametrized. One option is 'round-robin', 'unordered' and 'zip' would then be the third one?

[ivan-cukic]

No need to apologize.

So, zip would strictly be:

zip(channel<T1>, channel<T2>, ...) -> channel<tuple<T1, T2, ...>>

but the option to also support n-ary processes could be cool - haven't checked how you implemented the library, but something like a constexpr-if on std::is_invocable<F, T1, T2, ...> to choose whether to use std::apply or std::invoke (separate tuple args vs pass the tuple as the argument) could do the trick.

And join would be

join(channel<channel<T>>) -> channel<T>

[FelixPetriconi]

Currently, a channel consists of two ends: a sender and a receiver. Each receiver is associated with a process (e.g. a callable object or an instance of a process that has to implement certain functions.)

I am not that deep in functional programming - I have your upcoming book already on my order list :-) - so would a zip implementation qualify your expectations when it would go like this:

template <typename F, typename... T>
zip(F&& f, receiver<T>, ...) -> receiver<result_of_t<F(T...)>>

where F is a callable object with T... parameters?

Or must F take as argument a tuple<T...>?

[ivan-cukic]

Heh, I'm blushing :)

Usually, the zip function generates a series of tuples, and the zip_with calls an n-ary function. If you can not create one transformation that does both through static introspection, maybe zip + zip_with will do the trick (it would make it compatible with range-v3).

[FelixPetriconi]

Fixed in 1.3.0