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>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Message-ID:  <4A7BD551.6020804@morningstar2.co.uk>
Date:         Fri, 7 Aug 2009 08:18:41 +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:  <4A7AD930.2090106@residenset.net>
Precedence: list
Status: R

Lars Hellström wrote:
> Calc is possibly not the best example anymore, but I assure you it is
> not the only kind of preprocessing one might want to make. The basic
> idea is that rather than going
> 
>   \DeclareDocumentCommand ... {
>      \cleanup_as_A:Nn\l_tmpa_tl{#1}
>      \cleanup_as_B:Nn\l_tmpb_tl{#2}
>      \cleanup_as_C:Nn\l_tmpc_tl{#3}
>      ...
>   }
> 
> and refer to the scratch variables \l_tmpa_tl, \l_tmpb_tl, etc. where
> the values are needed, we can have #1, #2, etc. be these cleaned-up
> values throughout the body. The danger of generic scratch variables is
> of course that we don't know whether some other command (that our
> command calls) is using them too, whereas command-specific scratch
> variables are generally overkill.

What about providing some functions which can be used in <replacement
text> instead.  For example:

\DeclareDocumentCommand \foo { m m m } {
  \cleanup_as_A:Nn \l_foo_arga_tl {#1}
  \cleanup_as_B:Nn \l_foo_argb_tl {#2}
  \cleanup_as_C:Nn \l_foo_argc_tl {#3}
  ...
}

(An obvious example would be \MakeHarmless or something similar, an
interface to \detokenize would be another. Other cases?) I'd then
imagine passing the variables through by value (using a V function). As
I see it, neither case makes a difference to absorbing arguments.

>>> * The ability to have arguments assigned to token lists rather
>>>   than handed as macro parameters (lets one get around the 9
>>>   parameter limit).
>>
>>
>> If we attempt to keep things simple, then I think this is stretching
>> the limits of what we'd like \DeclareDocumentCommand to achieve.
>> Besides, I've never seen an argument for when >9 arguments are
>> actually necessary that couldn't be implemented in some other way
>> (e.g., keyval or csv list).
> 
> Not when creating new commands, no, but funny things happen as commands
> grow older (from xdoc and derivatives, I have some experience of this).
> With specifiers like o and s available, it is very tempting to every
> once and then add another feature to a command, by adding another
> argument or two; since they're optional, we stay backwards compatible
> throughout the process, and in a couple of years the 9 argument limit is
> reached. Star-type arguments in particular eat up a lot more parameters
> than it feels like they should when one uses the command.
> 
> Assign-to-token-list arguments offers a work-around when the limit is
> reached.

My experience trying to use xkeyval (where there are *lots* of optional
arguments) makes me very wary of making it easy to add too many
arguments.  There comes a point (probably 5 arguments in many cases)
where it is time to think about a different interface. Part of the idea
of LaTeX3 is to learn from mistakes made in LaTeX2e, and I think having
too many optional arguments fits into that category.
-- 
Joseph Wright