On 02/19/2002, 20:58 -0600, David W. Tamkin wrote:
Jacques proposed,
| :0 [flags & co] # Head inchanged
| ( # sub-block begins...
| * condition1.1
| * condition1.2
| # ...
| )( # this sub-block is ORed with the first one
| * condition2.1
| # ...
| ) # sub-blocks chain ends here.
| * condition3
| action
|
| Is this silly?
Silly, no (I used the word only because Erik offered it). But besides its
backward compatibility problems, it requires all the ANDs to have higher
precedences than all the ORs, so it's not very flexible.
Is `(' legal at the beginning of an action? If so, it could be replaced
by `**(', rather ugly, but look at it as a new syntax warning...
Closing is OK, I suppose.
There has to be
some way to specify whether to OR or AND a grouping block with another
grouping block (where a block could contain one single condition), and
moreover procmail would need to scan ahead to make sure that whenever there
are three or more blocks on a single level, they're all ANDed or ORed
together,
Procmail default syntax ANDs following conditions, so if an embedded
block fails, procmail jumps just out from this block, scanning ahead for
the closing `)', and examines the line:
- if the gluing `)(' is found, the failing block is forgotten,
following block is open...
- and if not, the closing `)' ends the block, block condition fails,
recipe or embedding block fails.
Blocks could be nested, I believe, up to min(user_brain, stack_size)...
Indenting can help, and comments should be allowed on the first line.
Perhaps ANDing or ORing could be specified as a level is opened?
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 ;
- as I prefer keeping the old syntax where possible. If you add a `U'
flag at some level (for union, 0 != O), one (block)condition, looking
like a good old time recipe, can be modified by one obscure flag ;
and what about nested blocks? Flags BHD make sense also, I'm afraid.
because "a or b and c" and "d and e or f" are ambiguous.
Which ambiguity? Generally, or I hope so, `a || b && c' defaults to
`a || ( b && c )', so it becomes
:0
(
* a
)(
* b
* c
)
action1
when `( a || b ) && c' is written as
:0
(
* a
)(
* b
)
* c
action2
and `d and e or f' defaults to
:0
(
* d
* e
)(
* f
)
action3
Of course the syntax is not symmetric between AND and OR, but like the
implicit priority anyway.
What I don't like is the slight visual difference between `A || B' and
`A && B', if A and B are large blocks:
(
* A
)( # OR = horizontal gluing
* B
)
(
* A
) #
( # AND = vertical sequence
* B
)
(gluing could be emphasized with `) U (' or `) OR (', but in Procmail
AND is already implicit, so...)
(end of well-balanced message :)
--
Jacques L'helgoualc'h
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail