I was closing and resolving all the rebol-issues tickets related to PARSE...considering them "resolved" if they are solved by UPARSE. Quite a lot of them were! 
Among the few tickets that weren't resolved was an old one in which BrianH talks about adding an /IGNORE flag to PARSE:
But to me... this sounds like a generalized feature being narrowly articulated as a PARSE wish.
What he's asking for is there to be a kind of iterator over a series which does not show some of its content. The closest concept that Rebol has potentially had for this would be a PORT!.
Here's some random imaginary pseudocode:
>> input: [1 2 3 4 5 6 7 8]
>> port: make-filtering-port input :even?
== #[port! [...]]
>> read/part port 2
== [2 4]
>> read/part port 2
== [6 8]
Ideally you could do this kind of filtering on a file on disk, a series in memory, a network stream, etc. Even if the file were gigabytes in size you wouldn't wind up creating a huge amount of data just to iterate over the even numbers in it.
This Kind of Mechanic Has Prior Art
(Well, at least when I assume you're not asking for the impossible. e.g. the data you're filtering is read only. And you're not expecting to be able to have some automatic way of inserting things in the middle of a disk file and sliding the contents up...writing back over only the even values. Sane requests here only, please.)
In the past I've often brought up Boost.ASIO, the C++ Asynchronous I/O library. It's for wiring up streams and layering them...dealing with buffering and disconnection exceptions and multi-platform eventing. The whole nine yards.
The filtering example I give above is actually one of the textbook examples of something you can do in Boost by building on streaming iterators:
struct is_even {
bool operator()( int x ) const { return x % 2 == 0; }
};
std::vector<int> input;
input += 1,2,3,4,5,6,7,8,9;
boost::copy(
input | filtered(is_even()),
std::ostream_iterator<int>(std::cout, ","));
That gives the output 2,4,6,8,
But it goes much further than that. You really can stack a streaming decompressor on top of a network port, and then stick a TCP processor and a TLS layer and an HTTP layer on top of that: https://dens.website/tutorials/cpp-asio/ssl-tls
There's a library for WebSockets in Boost.ASIO, and I've already talked about how I think it's important for the desktop executable to be able to speak to the browser automation APIs.
Plan: Strip PORT! Out of The Pure C Build
There's no reason that the pure C build can't read files into memory in one fell swoop, and be able to bootstrap itself. But I can say without a doubt that with the PORT! implementation behind the scenes today: "There's no gold in them thar hills."
So why not leave the pure C build with the basics of reading and writing files in their entirety... very simple and without any need for a PORT! model. Then start from scratch on ports embracing existing work as much as possible, and building on proven and tested code?
We'll keep the CALL facility written in pure C for now. That way the basic executables can always reach out to curl or wget or whatever, if they want to trigger something like a network request.
Starting From Scratch Can Advance Rapidly
It should be clear from UPARSE that when I start out tackling a problem anew with the stored up knowledge and experience from seeing the previous problems, the results can be good.
I've not really worked much on the port model, because there was no model there. But in keeping the code adjusted to stay running and be more convenient over time, a ton of design points on the core have been stressed. So as bad as much of the code is, it's been a proving ground for various pieces of the system.
But now...it's time. I think that basically wiping out pretty much all the PORT! code and starting again can go nowhere but up!
