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.
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.
Anyway, I wouldn't interpret the existence of workarounds as a
justification of that which has to be gotten around.
if the workaround isn't too painful, the need to do something drastic
isn't so great.
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.
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.
--
Kjetil T.