On Sat, 2005-02-05 at 17:01 -0500, Mark E. Mallett wrote:
I would like to include by reference, without going on about it further
here, my earlier remarks about choices of keywords that might be likely
to collide with future language enhancements. Those issues are still
important, if only to me.
please put forward suitable wording for use in the document?
Also I have a few new niggling comments, as follows.
3.
> "When a string is evaluated ..."
I'm not sure that the concept of evaluating a string has been
introduced, so the "when a string is evaluated" is not strictly clear
(even if everybody probably knows what it means). So perhaps lay the
groundwork of saying that this extension enables interpretation of
strings at the moment they are used during runtime , and then say "when
a string is interpreted..." or just change the word to "interpreted" :-)
I agree, "interpreted" is better.
3.2. Numbered variables
> For ":matches"...
> The wildcards match as little as possible (non-greedy matching).
Even though I am in favor of this: this is a refinement of RFC3028
(which is silent on the greediness issue). Does this need to be
explicitly stated? I would think this should be an item for 3028bis or
whatever the next SIEVE base draft is, as well. (Being able to specify
the :matches greediness would be a plus.)
I think it is essential that greediness behaviour is defined. it cannot
be observed by the mechanisms in 3028 (or 3028bis) since it doesn't
change _what_ matches, only _how_ it matches, so it is natural that the
facility which makes observation possible also defines what should be
observed.
> The first string in the list has index 1. If the index is out of
> range, the empty string will be substituted. Index 0 returns the
> number of strings in the list as a decimal number.
Hmm, I glossed over this before. There are other environments
(including typical regex implementations) where it's common to have
submatch 0 represent the entire matched string. Access to the number of
strings is useful, but so is access to the entire match (probably more
so than the number of matches, since that's predictable from the pattern
used). Since it's nice to be consistent with what people might already
be used to, I'd recommend having index 0 be the entire match, and something
else be the count of the matches. Maybe a special ${#} for the number
of matches.
I think too little is gained by this change to incorporate it at this
stage.
Or keep ${0} as the count, and add something else (e.g. ${*}) as the
complete match string.
explicit is better than implicit -- users can just add an extra pair of
parentheses. (this only applies to :regex. for :matches, the match
string is always equal to the source string.)
4. Action set
> An illegal name MUST cause a syntax error.
"MUST be detected as a syntax error" ? (at compile time? runtime?)
from RFC 3028, 2.10.6:
In any programming language, there are compile-time and run-time
errors.
Compile-time errors are ones in syntax that are detectable if a
syntax check is done.
so compile-time.
4.1. Modifiers
> More than one modifier can be specified, in which case
> they are applied according to this precedence list, highest value
> first:
I think this has been addressed before, but "highest value" is still
ambiguous because "highness" isn't really an attribute of a number, and
the word "precedence" implies doing things in numeric order, 1, 2, 3.
So some people, if not most people, will think of the "highest
precedence value" as having the smallest numeric value. Maybe:
More than one modifier can be specified, in which case they are
applied in reverse order of precedence value, i.e. from largest to
smallest, according to this table:
I would personally make it smallest value first, but either way as long
as it's clear.
I can do s/highest/largest/ if you think that's better. introducing
some "order of precedence value" will surely only muddle the issue.
5. Test string
I agree with another commenter's earlier remark that :count is silly.
Unless the intent is to count the number of matches, rather than the
number of strings? It doesn't say that, though-- and I don't really
know why that would be useful, either.
leaving it out will introduce an area of undefined behaviour, which IMO
would be bad and unnecessary.
--
Kjetil T.