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>                      
            <13962923-07A3-4C66-B144-E728DBC10183@gmail.com>           
            <4A82BC12.5050901@residenset.net>
            <4A8318FB.5030507@morningstar2.co.uk>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID:  <4A8566FF.1010805@morningstar2.co.uk>
Date:         Fri, 14 Aug 2009 14:30:39 +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:  <4A8318FB.5030507@morningstar2.co.uk>
Precedence: list
Status: R

Joseph Wright wrote:
> My feeling is that \DeclareExpandableDocumentCommand, if implemented,
> would be explicitly marked up:
> 
> "In general, document commands should be created using
> \DeclareDocumentCommand. \DeclareExpandableDocumentCommand is intended
> to be used only in *exceptional* circumstances where a fully-expandable
> function is *essential*. It has very restricted processing
> possibilities, when compared to the standard version."
> 
> I'd then expect us to basically support s, o, O and m type arguments,
> with any one \long forcing all to be long (probably by insisting that
> any + has to come before the first arg. spec.). I need to look at how s
> and o grabbing is implemented in such cases, so the exact restrictions
> are "yet to be determined". I would imagine that there would be no post
> processing in this case. (Of course, if there are good examples of where
> this needs thinking about, it can be looked at again.)

I've taken a quick look at things. I think that, when done by hand you
can in principal support rather complex things (for example " s o m m o
s m m"), but that this looks horrible if done with an automated system.
Further, I don't want to encourage people to use this function unless
*necessary*, and so far the number of real cases is *very* small.

How would the following sound:

 - All arguments either short or long (I think this is the only way in
any case), with "+" then required in front of each letter if any one is
to be long so that the input syntax is clear. So "+m m" or "o +m" raise
an error, whereas "+m +o" is allowed.

- Support only a subset of the possibilities. With "m ... m"
representing "one or more m arguments":
  = m ... m
  = t<token> m ... m
  = D<token1><token2><default> m ... m
  = t<token> D<token1><token2><default> m ... m
only (with short-cuts s, o and O allowed in the same pattern). Perhaps
not even the last one?
-- 
Joseph Wright