On 02/21/2002, 16:09 -0600, David W. Tamkin wrote:
Jacques responded,
| Is `(' legal at the beginning of an action?
Yes. It means save to a folder in $MAILDIR whose name begins with a left
parenthesis.
Sorry, I should have tried it --- bad filenames, IMHO.
As almost all characters are valid in filenames, (idiot|perverse)proof
backward compatibility is a problem, of course.
Using some variation around `**(' seems ugly ; maybe a new flag like `X'
for extended syntax should be mandatory?
When I suggested,
Perhaps ANDing or ORing could be specified as a level is opened?
He replied,
| I don't like that,
|
| - because OR is a binary operator, and I feel its "natural" place for
| readability is rather between operands, unless RPN|Lisp addiction ;
"RPN" -- really more polite to call it "RLN" --
?? I used the HP® acronym, and did not intended to hurt anybody...
Sorry, my english is not perfect, as you can read.
is postfix notation, with
the operator specified after the operands, as in dc or FORTH. What I was
considering was prefix notation, with the operator first, aka Lukasiewicz
notation. I wouldn't call one or another "natural"
I quoted it, meaning `infix is much more frequent' ; if you prefer
prefixed notation, you can use something like flags `U' for union, `I'
for intersection, and
:0 UI
* a
* b
* c
action
means prefixed `UIabc', or familiar `(a && b) || c' ; I believe that
this prefixed syntax leads to much more errors with long or complex
recipes.
For the same reason, Philip's proposal of embedded `(?-i)' is also,
apart other arguments, more flexible and user friendly than an exterior
`D' flag.
because algebraic notation doesn't occur in nature;
`nature' is also ambiguous :)
however, I'll agree that it's unfamiliar.
| when `( a || b ) && c' is written as
|
| :0
| (
| * a
| )(
| * b
| )
| * c
| action2
I'm sorry, but I don't see that. What in there gives (a||b) precedence over
the "&&c" part? Sequence?
No, `)(' gluing. Developing BNF definitions is a waste of time now, but
- the first `(' line opens a (maybe chained) block,
- any optional `)(' "glue" line ORs the results of adjacent upper and lower
subsequences,
- the `)' line closes the (chained) block.
The whole chain *is* equivalent to one 0-level condition, as `*' lines
in current syntax. Blocks may be recursively nested, of course.
I keep sequence as current procmail implicit ANDing, for compatibility.
Current sequential conditions can easily be pasted everywhere it make
sense, even if it is not recommended without thinking about it.
What if we wanted a&&(b||c), where a, being less
likely than (b||c), should be tested first?
You are right, the fourth case was missing:
:0:
* a
(
* b
)(
* c
)
action4
It is just a permutation of the quoted upper example. My proposal is as
commutative as the current sequence, except that you must pay attention
to side-effects, as useless ORed blocks need no evaluation, like that:
( a_true || b_useless) && c
as for conditions following one evaluated as false in current procmailrc.
I see no difficulties here, isn't it already the behaviour of Bash and
Perl ?
Your proposal, Jacques, works
well when all the ANDs have precedence over any of the ORs, but whenever any
OR has precedence over any AND, it doesn't adapt.
May be too verbose syntax, but it does, I believe --- have you any
counterexample?
| Of course the syntax is not symmetric between AND and OR, but like the
| implicit priority anyway.
An implicit default priority is one thing. Permitting no other priority is
quite another.
I meant dissymmetry of notations, as the `)(' symbol is roughly an OR,
when AND is hidden in newline.
As far as you use some parenthetic syntax, you should give higher
priority than implicit default to '()' pairs, unless you want an
avalanche of protests...
Too long, sorry, I'll be terser now.
--
Jacques L'helgoualc'h
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail