iteration pipeline builder

[Ichthyostega]

clearly a nice to have...

With the already existing nits and bits and helpers related to Lumiera Forward Iterators, we can easily build up pipelines for chained processing of each element yielded by a source iterator. The only drawback is that this kind of code tends to be bewildering for readers not familiar with functional programming (and especially function composition).

A pipeline builder could help to remedy this situation:

lib::explore(dataGenerators)
    .transform (λ-transform)
    .filter(λ-predicate)
    .effuse();

Based on the expression builder pattern, providing such a syntax should be almost trivial, since the somewhat tricky mechanics for applying a function is already implemented, and furthermore an universal ItemWrapper was also developed. What is more of a challenge however is to detect and adapt arbitrary iterable sources as input, and to handle the data types in the pipeline automatically. As a bonus, we get the possibility to pre-configure a pipeline, to be activated later, lazily, just by supplying a data source.

[Ichthyostega]

Meanwhile a rather elaborate construct emerged, known as IterExplorer (formerly TreeExplorer, see #1276), which is in fact created through a builder notation and also offers (amongst others) a filtering and transforming feature. So there is also some overlap and redundancy with the itertools -- and of course, the evolution of the C++ language also introduced a pipelining construct, which ideally should be adapted or assimilated for sake of interoperability...

[Undercover Agent]

Migration MasterTickets ⟼ Subtickets-plugin

[Ichthyostega]

Time to close this ticket.
The IterExplorer is it.

This pipeline builder framework was gradually developed over the course of several years, starting with a first, unsuccessful attempt to leverage the Monad Pattern from functional programming. After abandoning this first draft, a second attempt was made, based on the model of a pipeline builder. This design proved to be very versatile and tremendously successful. And it has evolved into an elaborate framework on its own, including a tree expansion mechanism, flattening and reduce operations.

Just recently, I have reworked and cleaned out the Itertools (#347), and modernised parts of our Iter Adapter framework (#349). Furthermore I am considering an extension to package an iteration as an opaque functor (#190). Overall, Lumiera got a mature and well integrated framework for lazy processing.

---

Remark regarding STL Ranges: These do not seem that important any more. Regarding the original iterator framework in the STL, the Range-TS mitigated some of the notorious annoyances — yet the abilities of our Lumiera iterator framework surpass the STL Ranges by far margin. In Lumiera, it was possible to do similar things already 15 years ago. And, what seems more important, our approach is more abstract and functional and less focussed on containers and data types.

[Ichthyostega]

Attach to parent #1119 (Iterator design review).