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>                   
            <4A804317.6050909@morningstar2.co.uk> <4A80508F.3030904@elzevir.fr>
            <0C83E480-14E3-4CD8-924E-3B9EA602E004@gmail.com>                   
            <4A810D6E.5050207@morningstar2.co.uk> <4A815596.6090308@elzevir.fr>
            <4A81DE5B.10506@residenset.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <4A825707.9070109@morningstar2.co.uk>
Date:         Wed, 12 Aug 2009 06:45:43 +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:  <4A81DE5B.10506@residenset.net>
Precedence: list
Status: R

Lars Hellström wrote:
>> I agree with this suggestion. IMO, xparse should provide general-use
>> post-processing functions, for the convenience of the user and as
>> example, and
>> let the user define more such functions, with the provided function named
>> \ArgFooBar and a recommandation in the doc that the user-defined
>> preprocessing
>> functions use a similar naming convention.
> 
> I don't think imposing a specific naming convention for processors is
> necessarily a good thing; half the time, a suitable function might
> already exist, with no intended connection document command argument
> parsing.

A convention would apply to what the team supply "out of the box". That
doesn't imply in any way that you can't then use something else.

> Sticking with xdoc2l3-style processors, one could imagine ?{<code>} as a
> generic "call out to function with :Nn syntax", with the meaning that
> xparse will first execute
> 
>   <code>\some_tl{<argument to process>}
> 
> and then take the contents of \some_tl as the processing result. This
> way, an xdoc2l3 @{h} or @{ho} argument could be specified to xparse as
> 
>   @{ ?{\MakeHarmless} }
> and
>   @{ ?{\MakeHarmless} o }
> 
> respectively.

Very much how I see things (although as I've said in another post, I
think the return has to be a toks).

>>> (2) + for \long, upper-case for defaults on optional arguments:
>>>
>>> \DeclareDocumentCommand \foo { o           >\MakeHarmless +m }
>>> \DeclareDocumentCommand \foo { O{default}  >\MakeHarmless +m }
>>> \DeclareDocumentCommand \foo { +o          >\MakeHarmless +m }
>>> \DeclareDocumentCommand \foo { +O{default} >\MakeHarmless +m }
>>>
>>> Both seem to look okay with the post-processing idea added in, I think.
>>> Based on Lars' comments about having a very clear syntax, can we agree
>>> on option (2)? If so, I can implement some of this and then see how it
>>> looks "in practice".
>>>
>> I'm in favour of option 2. It looks more "extensible", if extensions
>> are ever
>> needed in the future.
> 
> I'm not so sure it is more extensible. The tricky thing about being
> \long is that you have to pay attention to it throughout the
> implementation, often to the point of making separate definitions for
> long and short cases. Having \long-ness as a flag means you can't add
> just a short variant of a specifier, you always have to add short AND
> long versions.

Okay, the point here is that \long-ness applies to the grabber.
Everything else should be \long in any case: I've tried to indicate this
 in expl3.pdf, I hope. The general idea is that there are a very limited
number of cases where \cs_set_nopar: (\def) may be used in place of
\cs_set: (\long\def):

- For grabbing user input which should not contain \par (and is handled
by xparse anyway)
- For functions the programmer knowns can never be \long (those with no
arguments and those which process something internal that you know, say
\tl_map_function:nN { a b c } \my_short_function:N ).

Even then, I'm not sure the rest of the team even feel that the second
set of functions should not be \long :-)
-- 
Joseph Wright