[Lawrence Greenfield]:
From RFC 3028, section 8.2:
command = identifier arguments ( ";" / block )
argument = string-list / number / tag
arguments = *argument [test / test-list]
Your "set" action is implicitly extending 'argument' to allow for
something that is lexically identical to an 'identifier'. This
extension needs to be made explicit.
oh dear. I've missed that entirely.
(it's not lexically identical, ${_foo} is not allowed, though that
should be changed for internal consistency.)
You then have to resolve the parsing ambiguity, since
set variable "string";
can be produced by
command -> identifier arguments ;
-> identifier *argument ;
-> identifier variable *argument ;
so your grammar change here is
- argument = string-list / number / tag
+ argument = variable / string-list / number / tag
?
[...]
-> identifier variable string ;
OR
command -> identifier arguments ;
-> identifier *argument test ;
-> identifier test ;
-> identifier identifier arguments ;
-> identifier identifier *argument ;
-> identifier identifier string-list *argument ;
-> identifier identifier string *argument ;
-> identifier identifier string ;
which are obviously two different parse trees.
sorry, I don't follow this expansion. does this assume a different
grammar change?
so, we have (at least) three options.
a) change SET into taking two strings.
SET "from" "${1}";
the slightly nasty consequence of this is that the string
specifying the variable itself can contain variable references.
it is impossible to know at compile time whether the resulting
variable name is valid.
b) change SET into using a tag for the variable name.
SET :from "${1}";
this looks funny, and also creates a namespace problem if we add
modifiers such as :upper.
c) change the base grammar of Sieve. my suggestion is
- command = identifier arguments ( ";" / block )
+ command = 1*identifier arguments ( ";" / block )
as far as I can tell, this does not introduce any ambiguity.
> does require carry over? I'd say "no". variables shouldn't either.
It's not clear to me. Nor is it clear that sites won't want to
have variables cascade.
isn't this an issue that should be dealt with in an "include"
extension or something?
thank you for your feedback!
--
Kjetil T.