10 dec 2007 kl. 17.02 skrev Frank Mittelbach:
> Morten H°gholm writes:
>> Technically there wouldn't be any difference of course. Only the
>> implication that everywhere else, x means there is also an n base
>> function, which is also more or less why I chose the n form initially.
> and with good reason I think.
> Let us step back and reevaluate what the arg forms are supposed to
> \foo:abc % abc are placeholders for real arg specifiers
> is intended to be a short form for saying
> - do "a" with the first argument do "b" with the second and do "c"
> with the
> third argument prior to passing the argument values to the base
> - it is really only a short form of \exp_args:Nabc \foo:nnn
> It makes no statements about what \foo:nnn does with the arguments it
That is _one_ way to look at it, but probably not the only one; it
seems to me that:
* what started this discussion is that another model was plausible,
* the controversy is over cases where the two models disagree,
* what should be done is to (i) clarify the alternative model and
(ii) compare it to the original model, to see if the alternative
might actually be better.
Since it seems from the above that the original model was created as
nothing more than a naming scheme for shorthands, one should not be
surprised if some other model turns out to be more useful.
One principle that could be taken as foundation for what we've seen of
an alternative model is that the argument specifiers are about what is
_allowed_ in an argument rather than what will happen to that argument.
With this interpretation, an "n" specifier means "any <general text>",
whereas an "x" specifier means "<general text> without fragile
commands; will be fully expanded", and a "c" specifier means "<general
text> that expands to a sequence of character tokens; will be
\csname'd".[*] There are actually traces of this in the source, in the
form of the unused (but documented) specifiers "i", "d", "g", "m", "b",
and "r" which would then mean "<general text> that expands to an
<integer>/<dimen>/<glue>/<muglue>/<box-spec>/<rule-spec>; will be
interpreted as such".
[*] Technically, the description of the c specifier in the source is
too restrictive; the character tokens don't have to be category 11 or
This model probably calls for additional specifiers; e.g. booleans are
certainly common enough in the source to warrant a specifier of their
> Some people have suggested we shouldn't provide the short forms,
> though I feel
> that they make life much easier once you get the hang of it, but in any
> case they are only shorts for "manipulate some arguments prior to
> passing them
> to a function"
> There is a bit of inconsistency here in that something like T F are arg
> specifiers that give information about the argument purpose rather
> than about
> a manipulation of the argument and perhaps some of the concepts should
> reviewed and unified -- but the direction should be less arg
> specifiers not
I prefer not to have an opinion as to which model would be better, but
"T" and "F" seem quite useful, at least when reading code, so I
wouldn't want them abandoned.