Date:
Fri, 23 Oct 2009 12:41:24 +0200
MIME-Version:
1.0
Content-Transfer-Encoding:
8bit
Content-Type:
text/plain; charset=ISO-8859-1; format=flowed
|
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
|
|
|