Hi,
On Sat, Oct 23, 2004 at 04:38:04PM +0200, Kjetil Torgrim Homme wrote:
On fre, 2004-10-22 at 16:04 -0400, Mark E. Mallett wrote:
The bottom line is that if we're going to put variables into the
language, I'd like to see it done in a fundamental, fully integrated
way, while allowing for easy improvement and enhancement. RFC3028 made
this statement:
The language is not Turing-complete: it provides no way to write a
loop or a function and variables are not provided.
Yet all of those things have been put on the table in one form or
another (and I doubt that anyone is really surprised that they'd come
up). Once you've crossed the line to where you want something like
variables, you're going to want more and more out of them.
since the proposals are extensions, a system administrator is free to
support them or not. there is no doubt that Sieve scripts with
"variables" enabled can use more resources than scripts without them.
on the other hand, a very complex set of simple rules can be a burden on
the system, too. managesieve allows the administrator to set limits on
the size of the filter file, so the administrator can control that
complexity. (we have had complaints from users that the default limit
of 32 KiB in Cyrus is too low.)
"variables" can reduce load, too, if the user is able to simplify
hundred rules into a handful. this probably will only happen if your
users are predominantly tech savvy, so again, leave the choice to the
administrator.
Nothing to quibble with there; I'm not sure how it relates to what I
said, though. Re the large script files: people will indeed create
elaborate and large scripts. Variables (and other fundamental
constructs) that can give better expression of intent can possibly help.
Then again, giving people more language elements can also result in
larger things built out of those elements. I don't consider that a
downside if it means they are enabled to do elaborate things with them.
Things I would want to see out of the addition of variables to the
language include:
- Integration into the language syntax (e.g. not names enclosed in quotes,
not side-effects of referencing strings);
I agree with the first, but I don't know what other extensions would
have use for bare identifiers as arguments. regarding the second,
"$foo" is optimised into $foo by Perl's byte code compiler, and probably
by just about all other script languages.
That's fine, but not really related to my remarks. I prefer operations
that are explicit rather than implicit. So given my druthers I would
allow the script writer to apply a function to a string, as opposed to
enabling an extension that made all strings automatically subjected to
that function. Remember this is not targetted to the variables draft
but is a more global comment.
- Provision for multiple data types (even if only one is initially
specified);
better support for numeric types would be nice, but Tcl has managed just
fine with their "everything is a string" approach. extra actions for
doing arithmetic on strings can be added later.
example: result = count * 2 + 1
CALC "result" ["1", "$count", "2", "*", "+"]
(no discussions on the merits of RPN, please :-)
OK :-)
(I've had happy experiences with RPN)
Anyway, I wouldn't interpret the existence of workarounds as a
justification of that which has to be gotten around.
PS/Disclaimer: not that a disclaimer is needed, but I have an
implementation that includes typed variables, compound structures,
expressions, functions, etc.
sounds nice, but what do you actually use these for in your Sieve
scripts?
I have indeed used all of the above-mentioned constructs in delivery
scripts. I'm not sure great examples are important (or even possible
without a crystal ball- one can be surprised what people will do with
constructs they are given). What is important (IMHO) is to provide the
building blocks that makes complex tasks easier. One can argue about
whether such things belong in sieve; I'm certainly arguing that typed
variables do, at least at some point in the future. This does not
take anything away from the variables draft, other than wanting to
recognize that native variables should come along at some point.
-mm-