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

Re: Variables : list : scope : system : const

2003-05-10 06:07:38

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

 > 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}" ];

  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.

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

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

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

obviously not an argument which is going to convince me.

-- 
Kjetil T.