Hello everybody! This is my vision of and suggestion for a reform of the string
expansion language:
* The distinction between items, operators, and conditions is eliminated.
Instead there are only functions.
- All functions can be used as conditions. The truth value is the same as
with the "condition" ACL condition and router precondition today.
- Any punctuation character except $ can be used as the argument delimiter.
The character following the function name determines the delimiter.
- Characters that come in matching pairs - () [] {} <> - are used together
(like in Perl).
- Single and double quotes could possibly be used the the same way, with
single quote turning off expansion.
- Space can be the delimiter. If the first nonblank character after the
function name is not a valid punctuation character, then any amount of
consecutive whitespace separates arguments, except when the function
already has enough arguments.
- In fact, all bracketing delimiters and no delimiters can be used
interchangeably, so that this is no special case:
${if ${match_address $sender_address
${list:foo@???:bar@???}}
{The address matches}
[No match]}
- I don't think following nesting of bracketing delimiters that do *not*
enclose expansion functions or their arguments, like Perl does, is
worth it, though.
- Examples:
${substr:3:2:$local_part}
${tr/abcdea/ac/13}
- The special operators that take arguments separated by underscores have
to become normal:
${substr:3:2:$local_part}
* The list is a special data type. Some expansion functions return lists
(for example lookup, perl, and list, which is the generic list constructor).
The colon, or other delimiter, is only used as such in the configuration file,
not internally. Also, expansions are parsed when parsing list settings. This
avoids the need to double colons inside expansions in e.g. require_files,
as well as ${sg{<password>}{:}{::}} in places where an expansion result might
contain colons that are not intended as list separators.
This breaks with the principle that expansions are simple string
substitutions, but I think it can implemented quite easily by passing a
list_context flag to string_expand_internal() and converting to a string
before returning when a list isn't wanted (either by simply concatenating the
elements, concatenating with colons between, or by returning the number of
elements (like in Perl).
This should give the following advantages:
* The syntax becomes more coherent.
* Fewer braces overall.
* You can say ${eq $foo bar} instead of ${if eq{$foo}{bar}} :-).
* The code becomes simpler, even if there are more ways for the user to express
the same thing.
* The current syntax for most expansion items and operators is still valid.
But is this too much of a reform? Just how incompatible can the changes be?
Much should be auto-convertable and there were huge changes between Exim 3 and
Exim 4 that required manual attention.
--
Magnus Holmgren holmgren@???
(No Cc of list mail needed, thanks)
"Exim is better at being younger, whereas sendmail is better for
Scrabble (50 point bonus for clearing your rack)" -- Dave Evans
