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