

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer


A common occurrence for me is defining a meta-command that defines a whole slew of sub-commands. So the names of the sub-commands will contain parameters depending on the parameter passed to the meta-command, and the contents of the sub-commands will also vary a little depending on what the meta-command got. Often it won't be a direct substitution but rather a "if #1 is 'a' do \this else do \that", but \this and \that need expansion at define time, not call time.

Here's a very simple example just involving direct substitution:

\expandafter\newcommand\expandafter{\csname #1func\endcsname}[1][*]{%

Sometimes I worry that my commands are more complicated than they need be. For example, if I want to call a command with two arguments and the arguments expand before the command, here's how I've coded it:


So I'm looking for guidance on when and how to control expansion in defining macros. I strongly suspect that such cannot be given in a simple answer, so to make this a focussed question, let me phrase it thus:

Where's a good reference for writing TeX macros that includes advice on how to best deal with how to handle expansions?

Of course, if anyone can formulate some advice in short answer, I'd be only to happy to read it.

(Note: this was partially motivated by juannavarroperez's adaptation of my answer to this question where over 20 \expandafters got condensed down to just 1!)

share|improve this question
That’s a typical example of cargo cult programming. I think I’m allowed to make this observation without being insulting since my TeX code looks exactly like this, i.e. I have the exact same problem. :-( All this to say that I was about to ask the exact same question. – Konrad Rudolph Jul 28 '10 at 10:54
I accept the classification! I may be a professional mathematician, but in programming I am definitely amateur. In my defence, at least I know I'm amateur and would like to improve. – Loop Space Jul 28 '10 at 11:20
Andrew, just because I saw your example above: I recently discovered the LaTeX2e macro \@expandtwoargs\command{<arg1>}{<arg2>} which expands the two arguments using \edef before feeding it to \command. – Martin Scharrer Feb 15 '11 at 17:38
@MartinScharrer That's neat! Unfortunately, there does not seem to be an equivalent for three (or more?) parameters. :/ – Raphael Nov 30 '12 at 14:18
@Raphael: Just look at the definition of \@expandtwoargs and define a macro for three arguments. Should not be any trouble. – Martin Scharrer Dec 1 '12 at 8:46
up vote 142 down vote accepted

Expansion is a complicated area of TeX programming. I'll try to explain the key primitives involved first, then try to come up with some examples.

The \expandafter primitive expands the token after the next one. So

\expandafter\def\csname an-awkward-name\endcsname

will expand \csname before \def. So after one expansion the above turns into


which will then do its thing. Life becomes more complex when you want to step further ahead, and it soon becomes very hard to track what is going on.

The \edef primitive does a full expansion of what is given as its argument (in contrast to \def, which simply stores the input). So

\def\examplea{more stuff}
\edef\exampleb{Some stuff \csname examplea\endcsname}

will expand the \csname name\endcsname to \examplea, then expand that to leave a final definition of \exampleb as 'Some stuff more stuff'.

Now, \noexpand comes in by preventing \edef from doing an expansion of the next token. So if I modify my above example to read

\def\examplea{more stuff}
\edef\exampleb{Some stuff \expandafter\noexpand\csname examplea\endcsname}

then what will happen is that the \edef will execute the \expandafter, which will turn the above effectively into

\def\examplea{more stuff}
\edef\exampleb{Some stuff \noexpand\examplea}

Now the \noexpand will operate (disappearing in the process), leaving the definition of \exmapleb as 'Some stuff \examplea'.

We can use this ability to cut down on \expandafter use, but there are a couple of other things to know. First, e-TeX includes an additional primitive \unexpanded, which will prevent expansion of multiple tokens. Secondly, there are various special cases where you don't need quite so many \expandafter statements. A classic example is from withing \csname, as this will do expansion anyway. So you'll see things like

\csname name\expandafter\endcsname\token

which will expand \token before \name.

Back to your example. Using the fact that \edef will expand everything, I would write what you have as

  \noexpand\newcommand\expandafter\noexpand\csname #1func\endcsname[1][*]{%

What will happen here is that \newcommand and \MakeUppercase will be protected from expansion, and the \csname will only expand once. (Tokens which don't have an expansion don't need protection, which is why things like '[1]' are simply included as is.)

For your second example, you could instead to


I'm using a couple of extra ideas here. First, the group is used so that \temp is not altered anywhere other than where I'm using it. The \endgroup primitive will do nothing inside the \edef, and so will still be there to close the group when \temp is used. Secondly, \unexpanded works like a toks, and so will respect the \expandafter after it but before the {. This cuts down on an unnecessary \expandafter.

There are more wrinkles to this, and often there are several equally-efficient and clear methods. You are best off posting specific examples, and seeking advice on how they might be achieved.

share|improve this answer
Really nice and detailed explanation! Thanks for this! – Juan A. Navarro Jul 28 '10 at 20:43
Fantastic answer! I didn't know about '\unexpanded', and the automatic expansion in '\csname' is something that I know will be invaluable. – Loop Space Jul 29 '10 at 9:45

One difference of \expandafter and \edef is their behaviour towards protected macros.

eTeX provides the prefix \protected which can be used before \def and friends to define a protected, i.e. "robust" macro which doesn't expand inside an \edef context (like in \write). However, \expandafter does expand such a macro.

See the following example (works with eTeX and LaTeX):


\edef\withedef{x\pempty x}
\expandafter\def\expandafter\withexpandafter\expandafter{\expandafter x\pempty x}





\protected macro:->.
macro:->x\rempty x.

There are also the situations where TeX is expanding tokens, like after & and \cr inside a \halign. Here TeX stops when finding a protected macro without expanding it. However, if TeX is expanding tokens while in number reading mode like for \ifnum protected macros are also expanded.

share|improve this answer
The details of exactly when protected macros are not expanded are in the e-TeX manual. – Joseph Wright Feb 26 '11 at 20:06

Sometimes having a few helper macros makes the code much more readable. For example, in ConTeXt, typically your first macro will be written as


   {#1^{\ifsecondargument #2 \else * \fi}}

where \setvalue is roughly equivalent to the expandafter newcommand bit. (ignore the difference in the manner in which optional arguments are handled).

The second macro will typically be written as


where \expanded fully expands its arguments. \expanded is defined roughly in the same manner as Joseph's \temp macro, but uses \xdef instead of \edef.

share|improve this answer

For the particular problem of creating control sequences dynamically, I suggest you use something like

\def\csarg #1{%
    \expandafter #1\csname

You use it like

\csarg\mycommandbuilder <whatever> \endcsname

You can even use it like this

\csarg\mycommandbuilder <whatever> \expandafter\endcsname
    \csname <whatever2> \expandafter\endcsname
    \csname <whatever3> \endcsname

However, take care with the spaces. The above code constructs control sequences that have spaces in their names!

share|improve this answer

Your Answer


