Subject: | |
From: | |
Reply To: | |
Date: | Mon, 24 Aug 2009 17:30:38 +0930 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
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
|
|
|