[Marc Mutz]:
I want a single syntactical element for a common concept instead
of every extension brewing it's own thing. (Notify: $subject$ etc
substitution in the :message text; Imapflags: :(global)flags;
Variables: setdate).
The connection is the general variables syntax: ${}.
I see.
> this could be solved by making making a new list variable syntax,
> e.g., @{folder} becomes a list, while ${folder} becomes a single
> string with a single space as delimiter or something.
This might work - for imapflags. What about ${#currentdate},
${#size} (see below).
these aren't suitable for a list type, are they? list variables are
useful in other contexts as well, like
set "hdrs" ["To", "Cc"];
set "domains" ["njus.no", "usenet.no", "uio.no"];
if allof (address :localpart ["@{hdrs}"] "kjetilho",
address :domain ["@{hdrs}"] ["@{domains}"]) { ... }
if allof (address :localpart ["@{hdrs}"] "postmaster",
address :domain ["@{hdrs}"] ["@{domains}"]) { ... }
("@" may not be the best character, but I'll just leave it for now as
an example.)
And what about initial content?
an empty list seems best. interestingly, since this is an error:
set "foo" [ ];
you'd need to
set "foo" [ "@{undef}" ];
to reset foo to the empty list.
<sidenote>
I don't understand why imapflags requires it's internal set to be empty
on startup. Wouldn't it be more useful to allow implementations to
preload the set with the current flags? E.g. when applying scripts to a
selection of messages from an IMAP folder or in sequential script
("multiscript" environment) execution?
</sidenote>
your view sounds reasonable to me.
2)
part of me thinks strings will work OK. it just needs careful
programming to keep everything padded with spaces.
set "flags" "${flags} \\Flagged "; # note trailing space
if string :matches "${flags}" "* \\Flagged *" {
set "flags" "${1} ${2}";
}
Ugh. Too subtle. It's a open invitation for bugs in scripts.
possibly. if this code is given in the documentation, that would
reduce the error rate quite a bit. btw, it's wrong to blindly add a
flag, you need to make sure there are no duplicates (or else removing
flags becomes very difficult). shame on me ...
> # now we want to restore the flags to the values before the if.
> # or do we?
<snip>
you snipped my "sorry, I can't come up with a credible example", which
is what "or do we" is about. why would we ever need to restore the
flags?
My feeling is that trying to use an unknown timezone should flag
an error.
perhaps that is best. in the usual case, the argument to SETDATE is a
static string, and the error can be flagged at upload, which is nice.
I'll add that as a SHOULD in my draft.
Together with the relational extension and a rfc822-date
comparator,
please make it an ISO 8601 date comparator ...
<snip>
But rfc822 messages have rfc822 dates? Or is it the engine's job
to convert the string representation of the dates into ISO 8601
strings?
it is the engine's job to normalise the string representation into one
common format. but forget it, an ISO 8601 date comparator is not
needed, since a normal string compare is enough.
> I think your date test and SETDATE can co-exist.
I don't like setdate polluting the "user namespace" with unused
variables. How many people will need ${second} compared to ${year} and
${month}? If setdate remains, I'd like to see it write to ${#year} etc,
but I'd really prefer to have it's functionality go into a date test,
else why do we have a setdate and no setenvelope, setaddress,
setheader, setsize[1]? With a date test, all but the last are equally
superfluous. Should every foo test have a corresponding setfoo action
that optimizes away the otherwise necessary matches-set idioms?
that's the big question, isn't it? the matches-set idiom seems
clunky, a hack. I don't want to base the design of the language on
it.
It's simply needed. Size is just another example[2]. Whether it's good
or not that there are such variables, they're (implicitly) there even
in the Sieve base spec.
[2] And one which the variables spec needs to define, so it
addresses Ned's concerns about defining a concept and not
instantly making use of it.
which concept?
What do you mean with "generic mechanism"? Isn't "system variable"
such a generic mechanism?
every system variable will behave differently. I don't think that's
"generic".
--
Kjetil T. | read and make up your own mind
| http://www.cactus48.com/truth.html