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