ietf-mta-filters
[Top] [All Lists]

Re: General thoughts on variables

2004-10-26 15:37:36

On Tue, Oct 26, 2004 at 11:04:55PM +0200, Kjetil Torgrim Homme wrote:
On Tue, 2004-10-26 at 16:09 -0400, Mark E. Mallett wrote:
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:
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 [...]

since the proposals are extensions, a system administrator is free to
support them or not.

Nothing to quibble with there; I'm not sure how it relates to what I
said, though.

if the feature is integrated in the language, it can't be disabled.

Oh, I see what you were getting at- native variables implies more
complex scripts (or at least scripts that have a higher resource load)
which may be bad from a system administrator's perspective, vs a
variables extension which an administrator could choose not to enable.
But resource issues are resource issues, and language issues are language
issues; they ought to be addressed on their own.


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.

that would be a _less_ integrated feature.

What I said, perhaps in a fuzzy way, was that among the things you'd
have in a native implementation of variables is "integration into the
language syntax" rather than being things that were inside of strings.
I didn't say one thing was "more integrated" than another: the
"integration" in that sentence was about the inclusion of variables in
the language grammar.


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 [...]

I think they are.  I honestly can't think of a use for compound
structures and typed variables.  (particularily not abstract types,
which may or may not be implied by those two features.)  that doesn't
mean I doubt its existence, but without a use case, we shouldn't be
considering adding to the complexity.

I think if you disagree with typed variables, we are just going to
disagree, especially as I concede that you can apply operations to
string variables that interpret them in different ways- although
that's not my preference.

Structures are useful for anything where you have tuples that you
want to apply general processing to.  Off the top of my head, you
might have a set for each mailing list you are on:

 - list name (inside List-Id, say);
 - folder to file mail into;
 - an optional prefix to add to the header;
 - whether to add a "Mail-Followup-To" header for your local use;
 - what IMAP flags to set

etc.

You can consult an array of such structures and apply processing
generally.  You can even load the array from a file that's separate from
your script.  Or you can do all that stuff inline, one at a time.

I have the attitude that if you provide things like typed variables,
structures, and fundamental language features, people will use them, and
you can't always predict the things that people will do with them.  In
my original note I opined that in an eventual implementation of native
variables, only one data type might be provided (and of course I had
strings in mind), but that design should not prevent the eventual
addition of more types.  (I didn't say it quite that way, but it was
roughly the same.)



none of the competing e-mail filtering languages I know (procmail, MH,
Exim-filter) are significantly more expressive than Sieve.  I think that
indicates there is no great demand for it.

Really... seems to me that procmail is the poster child for demand for
extra features.  Most useful procmail scripts do all kinds of piping to
external programs to do things that can't be done inside procmail.
(There is the fact that the external program is often "formail," which
is part of the procmail package, but I don't think that negates this.)

Maildrop is a popular delivery language that seems to illustrate
peoples' desire for more expressive scripting languages.

mm


<Prev in Thread] Current Thread [Next in Thread>