Re: [sieve] Variable expansion issues

[[e-mail]]

> Hi Ned,

> [e-mail] wrote:
> > I actually disagreed with the exclusion of variables from the first argument to
> > set here. But that's water long since under the bridge.
> >
> [...]
> >
> > Since I disagree with the exclusion of set, I also am opposed to this
> > expansion. And even if I were to agree to this in principle (which I don't),
> > I would still object to this change on the grounds that it makes
> > currently conforming implementation nonconformant for no good reason.
> >
> [...]
> >
> > I understand the logic behind such exclusions. I just don't agree that the
> > supposed benefits are worth the loss in flexibility.
>  >

> Although I tend to agree with your appreciation for flexibility, I also
> value consistency. My implementation does not support constructing
> variable names with variable substitutions anywhere, since I assumed all
> variable name arguments to have similar requirements as the set
> command's variable name argument (e.g. for hasflag). Now I am wondering
> whether I should implement support for this anyway. Did you?

Well, I wouldn't go so far as to say "implement support", because that sounds
like a bunch of work. The routine in my implementation that computes parameter
values takes an argument specifying whether or not to perform variable
expansion in a given case. So for me changing the semantics so that, say, the
first argument of set allows variable expansions is simply a matter of changing
FALSE to TRUE in one call.

I even have the parameter set to TRUE for arguments to body, but if you
actually use a variable substitution in such an argument you're very likely to
get a run time error. As I explained previously, the alternative was not to
implement any form of body test.

				Ned