On tir, 2004-08-03 at 10:51 -0700, ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:
d) the EDITHEADER draft includes an action that needs the unexpanded
string to be passed to the procedure, since the action first per-
forms matching which may influence numeric variable references in
the argument. this is can be seen as a layering violation, and the
variable draft should state explicitly whether such extensions are
possible.
Vacation also needs access to the unexpanded strings for its internal hash
computations. This means that implementations need to allow for argument
evaluation to be done in two steps, first get the argument, then expand it.
Given that you have to allow for this anyway I don't see a problem with
letting
future extensions do this sort of thing explicitly.
"vacation" is a good example. perhaps a implementor's hint is off-topic
for the draft, but I suggest adding this to the end of 3 (just after the
next excerpt), before 3.1.
Tests or actions in future extensions may want to access the
unexpanded version of the string argument and do the expansion
after, e.g., setting variables in its namespace. The design of
the implementation should allow this.
or more tersely:
Future extensions may require access to the unexpanded version
of the string argument.
(it's a given the implementation provides an internal function for
expanding a string...)
Banning variable substitutions in body parameters may also be something
implementations want to do, but this is a somewhat different issue.
right, there is already this wording:
Strings where no variable substitutions take place are referred
to as constant strings. Future extensions may specify that
passing non-constant strings as arguments to its actions or
tests is an error.
[SETMATCH]
This would be easy for me to implement but I really don't care for it. In
particular, I find
setmatch ["", "", "", "foo"];
to be pretty awful.
I'd feel differently if this actually solved the value changing problem during
compound tests, but it doesn't.
okay, I'll kill the issue and stick to numeric variables unless someone
else weighs in.
a related question is what happens when a match fails. the draft
currently says that the numeric variables are reset, but this may
be inconvenient.
I'd prefer to have the values remain unchanged, but I can live with it
either way.
I'm currently favouring the same, mostly due to precedence of this
behaviour in Perl. I note that Sendmail claims to have implemented
"variables" already, and this is one of those small things which can
bite script writers if we change it around, although I think most
scripts will be straightforward and use a "SET" immediately after the ":
matches". My conclusion is that we can do the change.
--
Kjetil T.