R3-Alpha PARSE had a partially-implemented feature that Red did not carry forward...and I don't think that anyone uses...which is the do keyword.
What it does is perform a "DO/NEXT" step on the input as a code block, and matches the following rule against the evaluative result.
r3-alpha>> parse [reverse copy "aab"] [do "baa"] == true
I gather that things like the following were likely intended to work, but don't seem to:
r3-alpha>> parse [reverse copy "aab"] [do ["b" some "a"]] == false
It seems this feature was added to make it easier to do dialect processing where the dialect had code inline in the block you were processing...but not in a block or group. This means only the evaluator knows how much to advance to do one step of processing.
It can be a little hard to get one's head around, because it says
do [...] and yet the
... is a parse rule and not the code to be executed. But PARSE has this odd aspect in other operations like COPY, so it's something you're supposed to be used to.
Raises Complex Questions
The way this feature was implemented in R3-Alpha isolates it from participating in iteration or as the target of an outer rule, e.g.
r3-alpha>> parse [1 + 2] [set var do [quote 3]] == true r3-alpha>> var == 1 ; not 3, which you might expect
Other problems of the naive implementation expose just how non-integrated it is, like not working with THRU:
r3-alpha>> parse [1 + 2] [thru do integer!] == false
This is partially a problem with the code for DO, and partially a problem of PARSE being a somewhat organically evolved and ad-hoc codebase...where adding new operations that work coherently is just not that feasible. There was no "right way" to plug in such a primitive, so it was just hacked in however.
Interesting Feature To Keep In Mind. But Cutting It.
It took me a while when I first looked at PARSE's code to even figure out what it was supposed to do.
The broken implementation has hung around as a "thing to think about". But I think this forum post describing it serves that purpose better.
I've kept in mind the idea of being able to extend PARSE with new operations...and this is a good example of what could be a fairly simple test of that extensibility model.