Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
References: <4A7921CF.5020803@morningstar2.co.uk>
            <4A8EC449.4040509@morningstar2.co.uk>
            <19088.5371.517713.176151@morse.mittelbach-online.de>
Message-ID:  <F935973B-32E8-4FD2-9B02-6F55FCB73674@gmail.com>
Date:         Mon, 24 Aug 2009 17:30:38 +0930
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: Will Robertson <wspr81@GMAIL.COM>
Subject: Re: xparse
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <19088.5371.517713.176151@morse.mittelbach-online.de>
Precedence: list
Status: R

On 23/08/2009, at 1:25 AM, Frank Mittelbach wrote:

> It should therefore probably be better named xparse-2e or something  
> like
> that.

[snip]

> I would expect that once we have a clearer picture of how to do the  
> separation
> between layer -1 and layer 0 all this needs rewriting anyway
>
> I also hope (and expect) that once we are clear on how to write  
> specifications
> for layer 0 properly, that other interfaces for layer -1 will be  
> written, both
> because more than one might be needed and because we need some  
> trials to
> settle on what we want to promote as that standard layer -1 for latex3


 From these comments, I'm going to propose, tentatively, that with a  
change of name to xparse2e we can call this package "ready" in terms  
of interface and scope of application.

Let's think about the package in terms of three aspects:

(A) argument types
(B) separation of interface/implementation
(C) expandable argument processing

We've discussed point A extensively and, I think, produced a very  
workable result. This is the core of the package that I'd like to  
promote for package authors now.

Point B is something I think I'd like to work with more in the future,  
and as layers 0 and -1 start separating (see parallel thread) it may  
become more useful. Having said that, at this stage it's probably of  
little use so I don't expect much to happen with  
\DeclareDocumentCommandInterface at this point in time.

(I sort of feel that if it's to be used, it should be pervasive -- the  
benefits of separating interface/implementation are diluted if only a  
subset of commands are defined in such a way.)

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

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.

Will