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

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

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