I suspect I'm asking for magic, but I'll go ahead anyway. Suppose I have a command that accepts an arbitrary-sized list of comma-separated terms. One that we're all familiar with is \usepackage although of course we could all come up with dozens more. In the case of \usepackage, we can write:



\usepackage[ <comma-separated-options> ]{ <comma-separated-pkg-names> }

More generally, we might be given a command to be used like this:

\command{ <comma-separated-list> }

My question is, is there any TeX\LaTeX wizardry for constructing commands such as:

  ... possible wizardry ...
  ... possibly more wizardry ...

so that the effect of writing

\command{\mylist} and \command{a,b,c}


\command{ ...code... \mylist ...code... } and \command{a,b,c}

would be the same?

In other words, is it possible to construct a TeX\LaTeX command that can stand, be expanded and accepted in the compile where <comma-separated-list> would normally be accepted?

Motivation: (apart from the immense pleasure of learning new TeX-related things :) ) On multiple occasions, I have to pass a large non-fixed-sized list to several places, some being to packaged commands that, due to their complexity and the maintenance burden it would impose, I'm rather reluctant to dive into and redefine.


While some very good ideas have been suggested (thanks esp. TH and Will!), these solutions don't completely fit the bill. So, to ground my question somewhat, here are the specifics of the case I'm trying to solve. As background, my code consumes the same long list of values in multiple locations. While I could hard-code the list literally in all the places that consume it, for good and practical reasons, the idea of doing so is not at all appealing. I would really like to pass it as an argument, as I can for any other normal value. One of the (let's say) two places consuming the list is a command, \command, for which TH's and then Will's repeat, perfectly solve the problem. The other case where I'm struggling, however, is in my reusing the list in xkeyval command \define@choicekey, although the same problem would exist in the case of any other commands sharing the same type template. (FYI, I've tried hacking TH's nice solution to fit, but got nowhere particularly fast.) Here's an example list of values and the situations where I access them:


  \mylist%             <-- how can I consume \mylist here?

  \command{\mylist}%   <-- this problem is easily fixed with TH's nice solution
  • Is the question how to define a new macro that expands its argument or how to ensure that the argument to an existing command is expanded? I answered the latter while Yiannis Lazarides gave a suggestion for the former.
    – TH.
    Sep 3 '10 at 6:01
  • 1
    @TH. The motivation makes it pretty clear he wants the latter. Sep 3 '10 at 8:10
  • 1
    That's what I thought, but he got an answer to the former as well, so I figured I'd ask in case I just misinterpreted it.
    – TH.
    Sep 3 '10 at 8:31

Well if \mylist is defined before the \define@choicekey it is rather easy to expand it before calling define@choicekey. If \mylist changes afterwards you will have to recall \define@choicekey and hope that xkeyval does all necessary cleaning to remove trace from the former content of \mylist.



  • Ulrike, I am most thoroughly impressed! Your code (or rather the ideas contained therein) does exactly what I had set out to achieve. It took a while to see how you had broken down and then reassembled the sub-terms, before the pattern you had produced just clicked. Discounting the superfluous elements, I can certainly say that it is a most elegant solution. Many, many, many thanks! Sep 3 '10 at 14:03
  • This depends on e-TeX (probably a safe dependency) and it will only expand \mylist a single "level." Of course, that might be exactly what is desired.
    – TH.
    Sep 3 '10 at 18:16
  • @TH, rather than using native \unexpanded, I've replace each of these in Ulrike's solution with \etex@unexpanded using HO's etexcmds package. Yes, single level expansion is all I need -- it hurts my brain just thinking about fine-controlling "multi-level" expansion in this way :)) Sep 4 '10 at 1:05
  • Since you are already using \unexpanded, Ulrike, you could avoid using toks altogether, writing instead \unexpanded\expandafter{\mylist}. Also, I wouldn't include the last bit in the definition of \next, letting it be afterwards instead. But that's a matter of taste. Aug 22 '11 at 18:14

Unless I'm mistaken, I think you're essentially asking for a new way to process keyval input. All of the keyval processing packages (keyval, xkeyval, kvoptions, l3keys, etc.) are very careful to ensure that the comma-separated entries they receive are not expanded.

It would be theoretically possible to have code like


\processclist{a,\foo,b,\mylist,c,\bar,d} % etc.

only expand \mylist to insert x, y, and z into the processing but otherwise leave \foo and \bar alone, but keyval code requires a fair amount of care and attention to write.

An alternative might be to always fully expand your keyval arguments, if that is possible. If you just write


then assuming \foo and \bar are expandable then you'll be okay. (This is the same as what TH wrote earlier.)

Finally, if you can restrict the position of your clist-to-be-expanded so that it only and always occurs at the beginning of your options, then you could simply use \expandafter on it, as so:


The solution you choose (and what we can sensibly suggest) is pretty specific to the actual problems you're trying to solve.

  • 1
    Will's quite right. All of the comma-list reading code (apart from that used for the \documentclass options) avoids any expansion as you never know what makes sense in a general list.
    – Joseph Wright
    Sep 3 '10 at 7:04

The other answers are all very interesting in their own right, but the short answer to the question is simply No. You can't change the behaviour of \command solely by defining a special kind of \mylist.

  • Thanks, Taco, that's as definitive as can be and the answer I expected to receive. However, just for completeness, are you as definitive in your answer for the case of \command{ ...code... \mylist ...code... }, ie, inserting the invocation of \mylist within some expansionary and/or protective code? I suspect the answer in this case would be, "it all depends" (a la Will's and other answers), although I would be most interested to hear your thoughts. Sep 3 '10 at 9:33
  • 1
    It depends only on what \command does. If that expands its argument, then \mylist will work just fine. If it does not, then it will not. You can define \mylist in such a way that it does not expand when expansion is in fact asked for by the calling macro, but you can not define mylist such that it does expand when expansion is not asked for. Sep 3 '10 at 11:12

There's not really a way to do it in general. That said, you could easily write a macro that takes \command and {...code... \mylist ...code...} as arguments and expand to what you want.

  • TH, while Ulrike's solution (suitably deconstructed), provides a general solution to my question, yours provides a very clean solution for the more limited, albeit, more common case. Many thanks, your code helped dig me out of a ditch. :) Sep 3 '10 at 14:11

You can use the xkeyval package. It offers what you want and in addition you can define key value parameters as well.

  • xkeyval is a package for parsing options for use in implementations of new macros. The question asks how to interpolate the contents of (certain) macros into keyval lists passed to already existing macros. Sep 3 '10 at 8:09

Here's a couple macros I wrote a year ago to do just that:

I start by defining the "main" macro, \ProcessList:


This calls the supplementary macro \pr@cesslist:

\makeatletter % enables "@" to be used in macro names

To illustrate how this works, let's run through the expansion of \ProcessList{\a,\b}, where \a and \b are some user-defined macros. LaTeX starts by expanding \ProcessList to \pr@cesslist \a,\b,,. Glancing at its definition, we find out that \pr@cesslist eats everything that follows it until it hits a comma. (Note, however, that the space immediately following \pr@cesslist in \pr@cesslist \a,\b,, is not eaten). Next, TeX checks to see whether \a is the empty string (\empty is defined by \def\empty{}); since it isn't, \a is expanded.

Now, recall that TeX is reads everything as a stream of tokens; right now, after \a has been expanded, that stream is \expandafter \pr@cesslist \fi \b , , plus whatever comes after. What we'd like to happen is for \pr@cesslist to eat \b; but without the \expandafter, TeX would feed it both \fi and \a (since they both appear before the first comma). With the \expandafter, TeX jumps past \pr@cesslist, expands \fi once (which is enough to get rid of it), then jumps back, leaving the stream as \pr@cesslist \b , , plus whatever comes after.

From there, it's simple tail-recursion.

EDIT: OK, so I've modified the above macro so that it won't expand the list entries until after the list is processed; e.g., if \abs is defined by \def\abs#1{|#1|}, then \ProcessList{\abs,a} will expand to |a|.

%   \showthe\processedlist         <---- this line is for debugging purposes
    \the\processedlist} % unpack \processlist
        \appendtoks{#2}{#1}% append #2 to token list #1


The \appendtoks macro is, with some minor modifications, the \Prepend macro from page 154 of Eijkhout's TeX by Topic.

  • This does not work. You're creating a new token register every time you call \ProcessList. If you call it too many times, you'll run out of registers. You're not actually expanding the argument to the command which was what the question was about. If you trace the execution with your \abs and with \def\foo{a}, you see that you end up with \abs\foo in \processedlist and not \abs{a} which is what the OP wanted.
    – TH.
    Sep 3 '10 at 5:59
  • How would I fix the token registers thing? Should I just use \toks0 instead of creating a new token register? As for the \abs\foo, that expands to \abs{a}. Sep 4 '10 at 18:26
  • Put the newtoks call outside every macro. Once upon a time, \newtoks used to be "outer", i.e., impossible to put into the argument of any macro or definition. And it wasn't a bad idea. Aug 22 '11 at 18:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.