MIME-Version: 1.0
References: <201203031329.33709.pat_h@web.de>
Content-Type: text/plain; charset=ISO-8859-1
Message-ID:  <CANQYN6xxikyP+_B+dfsjdvj3+mcwYeqU13kEWELQm57jtUPEtQ@mail.gmail.com>
Date:         Thu, 5 Jul 2012 02:21:34 +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: Bruno Le Floch <blflatex@GMAIL.COM>
Subject: Re: Feature proposal for \csNewDocumentCommand
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <201203031329.33709.pat_h@web.de>
Precedence: list
Status: R

Hello Patrick,

Sorry for the long delay in answering you.  We had an internal
discussion on your proposal some months ago, but somehow forgot to go
back to you.

The short answer is that we are most likely not to provide what you described.

> Besides the great processing of a variable number of arguments via
> \NewDocumentCommand it's very handy to define commands with a name defined
> by some variable. Therefore I've been using the \csdef command from the
> etoolbox package, which can handle the variable name, but lacks the simple
> support for a variable amount of arguments.
>
> That's why I propose to have the combination of both worlds in the xparse
> package. The usage would be like:
>
> \csNewDocumentCommand{<csname>}{<variable arguments>}{<replacement text>}
>
> [...]
>
> I know, that xparse is for users and that there are other packages for
> package authors. As I am a user and never created a package, I guess that
> other users can make good use of the proposed command, too. So I had been
> glad if I had found this functionality in the xparse package.

Let me explain why we are not planning to add this functionality to
xparse. [Not sure that my arguments will be as clear as I'd like them
to be: it is starting to be a bit late in Europe.]

One important aspect of xparse's DocumentCommand declarations is that
they directly indicate the arguments that the function expects.  If I
open one of my colleague's document which includes some calls to
\NewDocumentCommand, I can immediately know how each function behaves,
at least at the level of the syntax:  either the command is standard,
or it is defined by his macros and I can look at the place where he
defined it, to get an idea of what arguments the function expects.

Now, this expectation of finding the definition of every document
command easily is broken if we introduce \csNewDocumentCommand.
Presumably, you are using it to define several commands with related
names.  The recommended way to do this is to write the
\NewDocumentCommand declarations in full, calling some internal macros
expressed using the expl3 code conventions.

I can't construct a good example right now, but perhaps if you send me
an example of where you would want to use \csNewDocumentCommand we can
find a different approach to do it.

In fact, even package writers should define all their document
commands explicitly.  For instance, we don't do

    \clist_map_inline:nn
      { New, Declare, Renew, Provide }
      {
         \exp_args:Nc \DeclareDocumentCommand
           { #1 DocumentEnvironment } { ... } { ... }
      }

to define \NewDocumentEnvironment, \DeclareDocumentEnvironment,
\RenewDocumentEnvironment, and \ProvideDocumentEnvironment in xparse.
Instead, we declare each of those 4 functions individually, calling
the appropriate internal macro.

Does that make sense despite the time of the night?

Best regards,
Bruno