## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Forum View Use Monospaced Font Show Text Part by Default Show All Mail Headers Message: [<< First] [< Prev] [Next >] [Last >>] Topic: [<< First] [< Prev] [Next >] [Last >>] Author: [<< First] [< Prev] [Next >] [Last >>]

I am revewing the messages form December (you see, I don't review the messages very
often), and what follows is may point about argument specifiers.

It seems clear that the problem is what do we want the arg-spec to specify. Two things
were proposed:

1. The original and current one. (Explanation following is form Frank)

>>\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 function
\foo:nnn

2. Let the specifiers tell what we can pass to the function according to how it will be
handled.

While the last one is quite appealing, when analysed I see a *BIG* trouble. The way the
argument is treated my change if the implementation of the function is changed (for
example, by pdfTeXing the kernel, as it was said). One may always update de doc, but
one cannot keep changing the names of kernel commands.
I see another trouble too. The casuistic (about manipulating arguments inside a macro) is
very wide. Too many arg-specs would be needed, and even then they the thefinition of
many of then could not be rigorous (or if they are, there will be macros that do not
exactly stick to what their arg-spec tells). This does not happen if the arf-specs are what
Frank's dewscripstion above tells.

<<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 function
\foo:nnn>>

is a very precise definition. One of the things I like more about TeX (seen as a
programing language) and TeX primitives is, that with all its oddities, the rules are
precisely documented and each primitive behaves exactly according to precese rules,
even if they are weird at some points.

So, my point is that I like few arg-specs with their current meaning and have well
documented in de doc the other part, i,e., what happens to the argument in the function
and hence what can be passed to it.

Andreas Matthias wrote:

>>When I first used these functions I added a lot of \exp_args:... and
>>\exp_after:NN just to realize afterwards that they are not necessary
>>at all. An x arg-spec would have helped me a lot to get things right
>>from the beginning.

Yes, but missinterpreting the specifications, or simply forgotting the precise rules, is
something that from time to time happens to everyone. I, for instansce, was continually
writing:

\expandafter\toks@a\csname toks@ #1\endcsname

(or something similar, now I can't remember) tilll I realized that the \expandafter was not
necesary.

But I agree that many people will be confused as you were. To avoid this, the
documentations that explains what arg-spec mean should also explain what they don't
mean, for example, saying that an n secifier that _not_ mean that the argument will not
get expanded inside the function.

p.s.: I defend the original model but I was _not_ one of the people coming up with it.

p.s. II: I also want the T and F specifiers to remain in existence.

Cheers,
Javier A.