[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.)
you didn't reply to this.
That's because I don't especially care how this works.
> 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.
the mentioned equivalence only concerns SET.
set "list" "@{otherlist}";
is an error. it MUST be written in a list context:
set "list" [ "@{otherlist}" ];
OK, but this doesn't change the fact that you've said that
set "var" "meep";
creates a list variable containing one element. I don't think you want
this...
Additionally, this fails to take into account the very real
possibility of implementation limits being different for strings
and elements of lists.
obviously my text needs fleshing out with details such as those.
> 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.
correct. that will always be the case since a list variable by nature
will have a non-constant number of elements. but if you prefer, a
string containing anything in addition to the list variable reference
could be disallowed with no loss of expressibility.
Making it even more complex and nonobvious.
> 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.
sorry, but I don't see your objection.
It isn't _my_ objection. Based on past experience with the IESG I think
there's a good chance of this proposal going down in flames with the IESG and
never getting published as an RFC.
This group needs to decide whether or not the value of list variables
is worth the possibility of not getting a variables specification
approved, period.
> 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.
I believe a cleaner syntax requires changes to the basic grammar of
Sieve.
Exactly.
Ned