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

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

Joseph Wright skrev:
> Lars Hellström wrote:
>> Finally, there is the issue that a processor has to put the argument in
>> a toks register. I understand this is for generality (only sane way to
>> pass along # tokens), but my experience with this type of API is that
>> one should make it easy to use commands that happen to already exist. In
>> this case, it would mean to also support a processor that would store
>> its result in a macro rather than a toks register, since I'm quite sure
>> this is what people tend to do unless they definitely need a toks register.
>
> Maybe I'm missing something here, but if we need the processed value
> returned in a named variable it should not matter whether it is a toks
> or a tl (or indeed anything else).

The point is that when specifying a processor, it's kind of a drag
having to introduce a helper function just for the purpose of glueing
xparse's syntax to that of an existing command really implementing the
operation; it would be much better if the syntaxes fitted from the
start. For operations that produce a sequence of tokens as result, I
believe the most common syntax would be the same as for \MakeHarmless,
i.e.,

\MakeHarmless<tl-to-set-to-result>{<input>}

(other examples more or less matching that syntax are \def and \edef).
Token registers, in my experience, is something you avoid using as
variables unless you have a specific need for them.

> All that needs to happen is
>
> \toks_set:NV \l_xparse_arg_toks <variable-used-in-processor>
>
> which is the same action if <variable-used-in-processor> is a tl or a
> toks.

Yes, but it is awkward to put that piece of code in the >{...}
modifier, since it must be executed *after* the actual processing step
has been carried out -- it pretty much requires a helper function to
rearrange things. Hence my suggestion that /xparse/ should supply that
piece of code, rather than rely on the user to do it.

Actually, a thing that worries me about the >{} syntax discussed so far
is that it presumes the programmer doing \DeclareDocumentCommand has
\ExplSyntaxOn, which I don't think is a safe bet; we're talking about
something which is somewhat like \newcommand. A better syntax might be

>{<variable>}{<processor>}

with the semantics that xparse will execute

<processor>{<argument>}

and expects to afterwards find the result in the <variable>,[*] which
it can then transfer to \l_xparse_arg_toks or perhaps pass directly to
the next processor. This adds the ability to use processors that leave
their result in a fixed place, but more importantly it avoid tying the
argspec syntax to implementation details of xparse.

[*] Okay, here that automagic "V" expansion type actually turns out to
be useful. :-o

Lars Hellström