User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
References: <4A7921CF.5020803@morningstar2.co.uk>                      
            <4A7A1505.4040604@residenset.net>           
            <DB76B425-0A88-43B4-9CF0-B92FAF159E37@gmail.com>           
            <4A7AD930.2090106@residenset.net>
            <8516B615-51AA-4D90-BB7D-A9E122AA0335@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <4A804317.6050909@morningstar2.co.uk>
Date:         Mon, 10 Aug 2009 16:56:07 +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: Re: xparse
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <8516B615-51AA-4D90-BB7D-A9E122AA0335@gmail.com>
Precedence: list
Status: R

Will Robertson wrote:
> So let's say we want to define \foo that takes an argument but has to
> sanitise it in some way before processing it:
> 
>     \DeclareDocumentCommand \foo {m} {
>       \my_sanitise:Nn \l_sanitised_tl {#1}
>       \foo_internal:V \l_sanitised_tl
>     }
>     \cs_new:Nn \my_sanitise:Nn {
>       % do something with #1 and save it in \l_sanitised_tl
>     }
>     \cs_new:Nn \foo_internal:n {
>       % do whatever \foo is supposed to do with #1
>     }
>     \cs_generate_variant:Nn \foo_internal:n {V}
> 
> From my not in-depth understanding of xdoc2l3, this can be dramatically
> simplified (I imagine) with something like
> 
>     \DeclareDocumentCommand \foo { ?{\my_sanitise:n} } {
>       % do whatever \foo is supposed to do with #1
>     }
> 
> Just to confirm -- have I got this thing sort of right? :)
> 
> With this sort of example, it seems pretty clear that this can save a
> lot of code that's just shuffling arguments around. (In the same way
> that manual optional argument processing consists of lots of
> intermediate functions that simply pass their arguments around.)

Hello Will,

That was my understanding also.  The question is then whether we
want/need to support this for all argument types or just one (or more)
specific ones (or of course at all).

In the first case, the interface currently used by xparse doesn't really
work (I think). You need to go with something like xdoc2l3, where each
specifier has a "processing" argument. My worry with that is, as I've
said before, that it may be overly complex as a replacement for \newcommand.

On the other hand, if you only want post-processing for a limited number
of argument types then it should work.  For example, you can imagine
having an argument type p ( = processed) to handle mandatory arguments
with post-processing:

\DeclareDocumentCommand \foo { o p{<processing-here>} } {
  % Code using processed #2
}

or

\DeclareDocumentCommand \foo { o p\ProcessingFunction } {
  % Code using processed #2
}

(This depends on whether you envisage using a single token for
post-processing or allowing more than one processing function.)

The question is then how many types of argument need post-processing. If
it is only m => p, then this looks okay. Duplicating all of the
specifiers, one for post-processed and one not, takes us back to needing
to fundamentally re-think the plan.
-- 
Joseph Wright