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>
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:  <4A80508F.3030904@elzevir.fr>
Date:         Mon, 10 Aug 2009 18:53:35 +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:  <4A804317.6050909@morningstar2.co.uk>
Precedence: list
Status: R

Joseph Wright a écrit :
>> Just to confirm -- have I got this thing sort of right? :)
>>
For the sake of the discussion, I'll assume you got it right, but I'd also like
a confirmation myself.

>> 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.)
> 
I agree. And it makes such a feature totally fit with the goal of xparse:
allowing the macro writer to go straight to the point without worrying too much
about user syntax.

> 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).
> 
I think that if you want to support this in xparse then it should be accessible
for all argument types. In my opinion, argument parsing and argument
preprocessing are orthogonal things, and the syntax should reflect this
orthogonality.

Besides, if you start offering preprocessing for one argument type, soon you'll
find out that someone needs it for another type, and either you will create new
type to fill the gaps, or you will see a collection of packages offering partial
solutions to the problem (a bit like in LaTeX2e you see a lot of partial
approaches for multiple optional arguments).

As a user/programmer, I expect the l3 tools to solve problems in a uniform and
rational way, thought not necessarily exhaustive.

> 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.
> 
Couldn't this processing argument be optional? If we go with the proposal of
- o (optional argument without default value)
- O{default}
then the processing argument would be the only optional argument to all
specifiers, so this shouldn't cause any confusion.

This should be a way of preserving the simplicity of xparse (basic) syntax while
offering part of the power of xdoc2l3.

> The question is then how many types of argument need post-processing.

IMO, all. I can't see a rational reason for authors to process only mandatory
arguments.

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

If I'm not mistaken, currently the plan is to allow a '+' modifier in front of
every specifier in order to allow for \par in the argument. Maybe it is possible
to add another modifier for preprocessing. This, or making the preprocessing
macro an optional argument to every specifier, doesn't seem to make the syntax
overly complicated.

Of course it is always hard to find the right balance between simplicity and
features, but in this case my personal preference would be to have it included.

Manuel.