User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
References: <4A7921CF.5020803@morningstar2.co.uk>           
            <4A8EC449.4040509@morningstar2.co.uk>           
            <19088.5371.517713.176151@morse.mittelbach-online.de>
            <F935973B-32E8-4FD2-9B02-6F55FCB73674@gmail.com>
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:  <4A926C87.7030201@elzevir.fr>
Date:         Mon, 24 Aug 2009 12:33:43 +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:  <F935973B-32E8-4FD2-9B02-6F55FCB73674@gmail.com>
Precedence: list
Status: R

Will Robertson a écrit :
> Point C is something I'm a little unsure of; I do think it's nice to
> have available, I just wonder when it will be used in practise. (It
> seems more useful in 2e than in LaTeX3 given their different approaches
> to robust commands.)
> 
The use case I was thinking of (in alignments) has nothing to do with
robustness: it's only about avoiding to introduce unexpandable tokens in the
input stream with the parser.

Btw, it's probably something that should be clarified in the documentation:
despite the name, \DeclareExpandableDocumentCommand is not really about
declaring expandable commands, but defining them with a purely expandable
parser. The command itself probably won't be expandable. At least in my example
in won't be, since the hole purpose of the expandable parser is that the
expansion of parser+command can begin with an unexpandable token, namely \omit
or \noalign.

> If we wanted to be really careful about things, I'd suggest dropping B
> and/or C from xparse2e and keeping them around in xparse(3) for future
> discussion. At the same time, I think it's fine to keep them there to
> promote discussion and experimentation straight away.
> 
Maybe they could be kept in xparse2e but the documentation should emphasize that
only part A is considered stable as of now. That way people can freely play with
part B and C, but the l3 team is still free to change them.

Manuel.