User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <4AE0BFB3.7080905@morningstar2.co.uk>
Date:         Thu, 22 Oct 2009 21:25:23 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: xparse processors
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
Precedence: list
Status: R

Hello all,

A while ago, there was some discussion about the xparse modifications. 
One idea that probably still needs a bit of thought is the "processors" 
code. As a reminder, a processor acts on an argument grabbed by xparse 
before passing to to the code implementing a function:

\DeclareDocumentCommand \foo { >{\Processor} m } {
   Code including a processed #1
}

Currently, we have the idea:

 >{ \SomeFunction }

where \SomeFunction should take one argument and return the result in 
\l_xparse_arg_toks. The processor simply has to absorb one argument, but 
does not have to be a single token. Lars pointed out that this requires 
\SomeFunction to be specially "crafted" for xparse, which might not be 
desirable.

One alternative would be to include the name of the return variable in 
the argument:

 > { \SomeFunction } \ReturnVariable

or

 > \ReturnVariable { \SomeFunction }

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. The other alternative is to avoid a 
return variable entirely, but I'm not sure that is universally 
applicable (a processor cannot be assumed to be expandable).

This is one thing I'd hope we can tie down in xparse one way or the 
other soon. Does anyone else have ideas for this?
--
Joseph Wright