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


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