[Ned Freed]:
> what's your preferred alternative in the imapflags case?
A string containing a list of flags separated by spaces. This is
hardly rocket science.
a string with a predefined name, then? (to cater for MARK/UNMARK.)
> > There are also very substantive syntactic difficulties with making
> > such usage compatible with the base sieve specification.
>
> please state them so that they can be addressed.
They have all been stated before. For exmaple, what syntax do you
use to plug a list variable into an argument to a test? "&list" is
poor. What about "&list &list"? What about ["&list", "&list"].
my current suggestion:
"@{var}" is an error except in a list context. a list variable in
string context interpolates as the concatenation of each value in the
list delimited by a single space. a string variable in list context
is handled as a list with one element. these are equivalent:
set "var" "meep";
set "var" ["meep"];
Just because there are no cases now where a string and a list containing
a single element aren't equivalent doesn't mean such cases won't arise
in the future. Additionally, this fails to take into account the very
real possibility of implementation limits being different for strings
and elements of lists.
a string containing multiple list references will be split on the
references, and the list will contain the pre-, in- and post-fixes as
elements in the list.
["@{var} @{var}!"] => ["meep", " ", "meep", "!"]
The effect of these expressions are now entirely nonobvious. Now a simple
count of the elements no longer suffices to determine how many elements there
are in a list.
There are probably a bunch of additional problems here I can't think of right
now.
Sure, you can work around all of this. But it keeps getting uglier
and uglier.
ugliness is in the eyes of the beholder. :-)
I disagree. This is ugly no matter how you slice it. So ugly, in fact, that I
fear it will get very substantial pushback from the IESG.
And for what? A feature that is nice to have at best?
possibly, but lists are a widespread occurence in Sieve, and I think
it does make sense to be able to represent them in variables.
I might agree had the syntax for adding them been cleaner. But it isn't, so
I don't.
> > You may not want to deal with them, but it may make sense to
> > implement things using a multi-tiered storage approach.
>
> what do you mean?
I mean I may not want to create variables like year, month, day,
and so on on demand rather than having setdate poke them into the
same structure used for user-defined variables.
alright, so if I understand you correctly, the "multi-tier" is that
you store the time-of-day internally, and populate the user-defined
variables from that when asked to.
Correct.
Exactly. The primary problem with list variables is that they
clash very very badly with earlier design choices, so much so that
we lose considerable language coherency by adding them. Now, you
can argue that earlier design choices were poor ones, but that
doesn't make them go away.
I honestly can't see why list variables clash more badly than plain
variables.
Your own examples demonstate the truth of this assessment more adequately
than anything I could write. This is really pretty awful.
Ned