User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
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>
            <4A926C87.7030201@elzevir.fr>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <4A92757A.3080402@morningstar2.co.uk>
Date:         Mon, 24 Aug 2009 12:11:54 +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:  <4A926C87.7030201@elzevir.fr>
Precedence: list
Status: R

Manuel Pégourié-Gonnard wrote:
> 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.

I've altered the documentation a bit to reflect this: probably still
needs a few "cycles" to get everything clear.

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

That would probably be my favoured approach also. The obvious question:
is everyone happy that \DeclareDocumentCommand, etc., is now "right" at
the interface level?
-- 
Joseph Wright