Streams library 2.0 development, part 1

Here’s my proposal for an almost universal keep / map combiner on streams. No metaprogramming! The list of operations is executed from right to left, or from the bottom up:

This is the code:

with:

Is it useful? hmm ... not sure - but it was fun to create! I used a kind of "may be" mechanism for integration of boolean operations (~ keep on a 1-item scale):

  • the item to be operated on is formatted as a list: (value);
  • if the operation is a reporter, the result of the operation is also formatted as a list: (intermediate);
  • if the operation is a predicate, the result is a Boolean: true = keep; false = discard.

With a predicate as operation, if the item (or intermediate result) to be operated on is a list, I have (for now) followed the convention of Snap! command-if and stream-keep.

Runtime performance

Logic programming DEVLAB script pic (13)

Less ambitious: map -> keep

Something else

I wonder if the run time performance (and memory use?) of streams could be improved by using a different data structure. During my research of partial sorting (in 2022) I developed a "Mickey Mouse" special purpose version of the streams mechanism, which proved much faster. By now my understanding of streams has much improved, shall I (at least briefly) look into generalizing this approach? As far as I can see there's only a few blocks that would have to be rewritten, notably: head of stream (), tail of stream (), () in front of stream (), and optionally: is stream () empty, and the empty stream. Plus a conversion block from "old" to "new" perhaps.