User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
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>
OpenPGP: url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x50A89B42
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <4A815596.6090308@elzevir.fr>
Date:         Tue, 11 Aug 2009 13:27:18 +0200
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: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= <mpg@ELZEVIR.FR>
Subject: Re: xparse
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <4A810D6E.5050207@morningstar2.co.uk>
Precedence: list
Status: R

Joseph Wright a écrit :
> I'd wondered about something similar. Looking at xdoc2l3, I think there
> are a couple of obvious post-processors. One is \detokenize given a
> "design" name (\Detokenize or \MakeString?), and the other is
> \MakeHarmless. Perhaps also a de-babel function to deal with active
> characters: \PunctuationOther? (Perhaps all of the functions should make
> it clear they are argument post-processors? \ArgDetokenize,
> \ArgMakeHarmless, etc.)
> 
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.

> In any case, I'd imagine any post-processor being a function of one
> argument. Internally, they'd do something with a temporary variable,
> then put the value of the variable back into the input of the underlying
> function defined by <code> in \DeclareDocumentCommand.
> 
That's exactly how I imagine it.

> I'd stick to post-processing if given the option. Pre-processing can
> lead to things which only work if the defined function is not nested
> (back with % again), and I'd prefer not to imply that can work. e-TeX
> makes post-processing catcodes possible, so saying "first the argument
> is grabbed, then it is modified" seems okay.
> 
Maybe I confused pre/post in my previous message. I always meant post-grabbing
and pre-actual-function-call processing :-)

> (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.

>> In terms of offering expandable optional arguments, I think Joseph's
>> "wright" that this can't possibly work with more complex argument types;
>> I might be wrong, however. Perhaps this can be something to revisit with
>> LuaTeX.
> 
> I'm very reluctant to introduce something where we end up with a complex
> warning about what it is for. You can imagine using something like "e =
> expandable test for optional argument", but explaining what it is for
> and how to use it then becomes very complicated. If we really do want
> something like this, I'd think a separate function
> (\DeclareExpandableDocumentCommand) might be better.

I think I agree. As you pointed out, the capabilities of a purely expandable
parser would probably be quite different (no post-processing, less precise
peeking at least), so using a different function for defining it makes sense.

OTOH, as you mentioned in another message, it would be very interesting to
detect trivial cases like only 'm' arguments and use the trivial (hence purely
expandable) parser in this case with DeclareDocumentCommand.

Manuel.