Will Robertson skrev: > On 23/10/2009, at 6:55 AM, Joseph Wright wrote: > >> This would allow things like: >> >> > \ReturnVariable { \MakeHarmless\ReturnVariable } >> % Will absorb one more argument, as required >> >> (using \MakeHarmless from xdoc). That doesn't work at present as the >> return has to be in a toks. >> >> As Lars points out, that is quite a bit more flexible at the cost of a >> little complexity in the syntax. > > > I'm not sure that I see how this is any more flexible? > Oh, simply that your argument processor doesn't have to be hard-coded to > use \l_xparse_arg_toks. > But hang on, can't you do the same thing at present by just writing > > > { \MakeHarmless\l_xparse_arg_toks } > > ? From my point of view, there were two issues. The first issue is that the given "return value register" \l_xparse_arg_toks is a toks when (in my experience) values (at least non-numeric values) are more commonly returned by defining a macro. This thus has to do with the ability to reuse existing code (in packages and such). The second issue is that the name \l_xparse_arg_toks would not fit in at all if using \DeclareDocumentCommand in e.g. the preamble of a document; one would have to fiddle around with the catcodes just to be able to type it, and the name is unintuitive. I suppose a compromise could be to use a fixed command name in the same class as \DeclareDocumentCommand -- e.g. \XparseResult or \XparseProcessorResult -- and do \let\XparseResult=\l_xparse_arg_toks just before each processor; then the user can use this high-level name and not have to worry about the low-level LaTeX3 name. Furthermore this provides support for mixing macro- and toks-setting processors, as code that ends up doing \XparseResult={...} will access the toks register, whereas code that ends up doing \def\XparseResult{...} just breaks the association of \XparseResult to \l_xparse_arg_toks (as opposed to breaking xparse as a whole). Either way, V-expanding \XparseResult will recover what had been stored. Lars Hellström