Changes between Version 1 and Version 5 of Ticket #874


Ignore:
Timestamp:
2026-04-07T16:22:37Z (5 weeks ago)
Author:
Ichthyostega
Comment:

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.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #874

    • Property Blocking 283, 349
    • Property Blockedby 347
    • Property Sub Tickets → 347, 1117
    • Property Parent Tickets → 283, 349, 943, 968
    • Property Resolution → done
    • Property Status new → closed
    • Property Type planned → todo

  • Ticket #874 – Description

    v1 v5  
    11clearly a ''nice to have...''
    22
    3 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).
     3With 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).
    44
    55A pipeline builder could help to remedy this situation:
    66{{{
    7 treat_all(dataGenerators)
    8   .apply (someNiftyTransformation)
    9   .filter(someSketchyPredicate)
    10   .buildVector();
     7lib::explore(dataGenerators)
     8    .transform (λ-transform)
     9    .filter(λ-predicate)
     10    .effuse();
    1111}}}
    1212
    13 Based on the expression builder pattern, providing such a syntax should be almost trivial (because the rather challenging part, that is, defining those transforming and filtering template functors, is already done). As a bonus, we get the possibility to pre-configure a pipeline, to be activated later just by supplying the source.
     13Based 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.