LATEX-L Archives

Mailing list for the LaTeX3 project


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 >>]

Print Reply
Lars Hellström <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Thu, 3 Sep 2009 14:43:19 +0200
text/plain (63 lines)
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, 


(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


with the semantics that xparse will execute


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