LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

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

Print Reply
Subject:
From:
Lars Hellström <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Fri, 23 Oct 2009 12:41:24 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (54 lines)
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

ATOM RSS1 RSS2