Both Martin Ramsch's and Stan Ryckman's recommendations at the start of this
discussion struck me as problematic: for one thing, it's hard to honor mixed
ANDs and ORs without subgrouping. (Otherwise they're ambiguous, and I don't
know a way to get the kinds of logic tests we've been discussing into the
unambiguously unfolding forms that Mr. Ryckman was talking about.) I began
to get the hunch that adding both ORing and subgrouping of conditions to the
syntax would bloat the code beyond Mr. van den Berg's usual tolerance for
the cost of a suggested new feature.
An `o' or `O' flag would be a useful, simpler way to code ORing (when we
can't accomplish it simply by alternating regexps with a pipe symbol) than an
inverse DeMorgan.
It would mean, "OR, do not AND, all unweighted conditions on this recipe, and
skip ahead to the action as soon as any unweighted condition passes; if no
unweighted condition passes, then go by the total score of the weighted con-
ditions." If there are no weighted conditions on the recipe, that would be
equivalent to "OR, do not AND, all conditions on this recipe, and skip ahead
to the action as soon as any condition passes." (We can get the same results
from procmail now by putting the maximum weight on all conditions that other-
wise would be unweighted.)
That alone might not bloat the code too much (or maybe it might). But I'd
guess that it would be bulky to code for mixing ANDs and ORs and grouping
them properly within a recipe.
More confession: the double inverse DeMorgan I posted as an equivalent to
(A | B) & (C | D) doesn't bother me in the least, but the suggestion I had
for (A & B) | (C & D) felt very unsatisfying because the action line had to
be repeated: I didn't really OR the results of the two ANDs. I prefer it to
forking another program, to setting a variable to test later, and to the
inefficient scoring trick I posted, but if I ever think of a way that is IMO
better yet, I'll post it then.