On Fri, Sep 16, 2005 at 07:51:48AM -0700, Marc Perkel wrote:
> OK - I want to throw out a proposal to make a major change to Exim - the
> scripting language. And before you all start screaming - the idea would
> be to leave the existing language in for compatibility.
I guess I used up my supply of suggestions for radical changes for this
week, so let me suggest a change not as large. :-)
You describe a problem I thought about before as well. I am sure Philip
can tell me what I overlook.
Exim does support boolean expressions as first argument to "if", so it
has an idea of typing, but conditions do not take boolean expressions,
but strings as input.
> condition = "${if and { \
> {!eq {$interface_address}{127.0.0.1}} \
> {!def:h_X-Spam-Status:} \
> {!def:h_X-Mailman-host:} \
> {!eq {$received_protocol}{ctyme-spam-scanned}} \
> {!eq {$received_protocol}{local}} \
> } {1}{0}}"
Right, that's the problem, and it is not even as bad as it gets
sometimes. I would be glad if I could write it that way already:
condition = and {
!eq {$interface_address}{127.0.0.1}
!def:h_X-Spam-Status:
!def:h_X-Mailman-host:
!eq {$received_protocol}{ctyme-spam-scanned}
!eq {$received_protocol}{local}
}
In this example "if" is removed, as "condition" takes a boolean
expression. Further, "and" takes a list of boolean expressions,
too. Since the whole is not a string, but a boolean expression,
backslashes are not needed.
You suggest to modify "eq" from a function to an operator. I think
the expansion language is purely functional. Operators would introduce
associativity and precedence and I am not sure I would like that. It is
way easier for simple examples, and allows a whole new class of mistakes
for more complicated ones.
Somehow I have a feeling, though, that I miss some fundamental aspect
that explains why "condition" works the way it does and that's why I
didn't suggest the above before.
Michael
