User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713
            Thunderbird/14.0
MIME-Version: 1.0
References: <CAFUtaNEMNbgCN0eDpX3td-50wx0pD+0kyEY4T+NU0jyneUsNow@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <50372259.7040300@latex-project.org>
Date:         Fri, 24 Aug 2012 08:42:33 +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: Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
Subject: Re: What does the `_x:` suffix mean?
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <CAFUtaNEMNbgCN0eDpX3td-50wx0pD+0kyEY4T+NU0jyneUsNow@mail.gmail.com>
Precedence: list
Status: R

Am 24.08.2012 04:37, schrieb Joel C. Salomon:
>
> What's the difference between the `:x` signature and the `_x:n`
> suffix+signature?

Bruno gave a very nice and elaborate explanation. I just want to
highlight one point here as it is central to the idea of the "argument
spec/argument manipulation" syntax.

The main idea of that syntax (and I'm not sure we have explained that 
well enough) is

  - that it describes how arguments are manipulated/modified *before* 
they are passed to a "base" function.

  - they do not describe what happens inside the function with the 
values passed as arguments.

The key point here is really that the manipulation happens *before*.


Base functions those that have only :n or :N arguments. All other 
arg-specifiers manipulate arguments first and than pass the result to 
the base function.

Conceptually this means

  - there should always be a base function defined not just a variant

  - variants (ie, those with :x or :o or ...) are defined via 
\cs_generate_variant:Nn

  - or if not, they behave *exactly* as if defined this way (ie, 
sometimes for very heavily  used functions it might be better to code 
them differently for speed reasons (but we expect that to be not 
necessary often or outside the kernel)

A corollary of this is that if the kernel, say, provide \foo:nnn but not 
\foo:nxo and some package needs it, it will be safe for the package to go

\cs_generate_variant:Nn \foo:nnn {nxo}

and that will be true regardless of some other package doing the same or 
the kernel (or some other package) defining an optimized variant 
\foo:nxo at some point in the future.


Now when we ran the  last consolidation round on function names, we 
noticed that we violated this principle sometimes and in cases where we 
felt it was important to indicate to something gets e"x"panded inside as 
part of the function behavior we introduced _x as part of the function name.

frank