Philip Guenther recapped the code so far and added a new wrinkle:
| The one optimization that I can still see is to add the following
| condition to the recursion recipe:
|
| :0
| * EXCESS ?? ^[1-9]
Philip, don't you mean
* EXCESS ?? ! ^[1-9]
or perhaps
* EXCESS ?? ^[-0]
| * HEADERLINES ?? $ $REGEXP(.*$)*\/$REGEXP(.*$)*
| {
| ...
| }
|
| That'll avoid the recursion if we've already gone positive. Note that
| this is a Good Thing if just to avoid the copies that the very next
| condition will cause in coping the matched text back and forth from
| HEADERLINES to MATCH and back again.
That is a *very* good idea, and there are even more reasons: if we already
know what we want to know then we can relieve the system of the time and the
strain of the extra cycles and extra file descriptors (each open INCLUDERC
requires an open file descriptor).
| HOWEVER...
|
| With this added condition, it becomes more complicated if you want to
| get the total count, with no upper limit criteria as is true in the
| original goal. If you think it unlikely that you'll need to do that,
| or the extra bother of having to set EXCESS to negative 10 million
| doesn't bother you, go ahead and add the condition.
That's why I didn't think of it before: the one time I wrote recursive code,
we had to parse the entire search area and the only reason to quit was the
lack of any more matches.
Here's a way around it: in the main rcfile, just before the INCLUDERC call,
ENOUGH = "^[1-9]" # to come back as soon as we reach plus territory
# ENOUGH = "!" # never enough; uncomment to keep going and get final total
And in the included rcfile,
:0 # Recurse if $EXCESS is not yet enough and we can find $REGEXP again.
* EXCESS ?? $ ! $ENOUGH
* HEADERLINES ?? $ $REGEXP(.*$)*\/$REGEXP(.*$)*
{
...
}