From my understanding a control sequence is ended by any non-alphabetic character such that \mycsA is one token, but \mycs1 is two tokens. This means things like starred commands \mycs* are actually two tokens with the * being the first "argument" to \mycs (even when \mycs isn't defined as taking an argument. This seems to be more confusing than defining a much smaller set of characters that end a control sequence (e.g., white space). What is the advantage of TeX behaving the way it was designed?

EDIT I realized from David's answer, that my focus on terminating characters is incorrect, and I am more interested in the advantages/disadvantages of only allowing a small set of characters to be easily used in command sequences.

  • note that one-character control sequences allow non-letters: \1 for example. However a space coming next will count as space, try: \def\1{1}\1 \1\1, so these one-non-letter-cs can set traps to the unwary.
    – user4686
    Feb 26, 2013 at 14:20
  • 2
    @user700902 almost all of ‘basic level’ tex consists of a series of traps for the unwary. that \1 doesn't behave like \a is just the way the cookie crumbles; knuth’s not changing his code now, whatever else... Feb 26, 2013 at 17:40

3 Answers 3


Why? questions can not really be answered except by the person who originally designed the system. But in most languages (certainly most languages of the era) the grammar for names of a language is defined by explicitly listing the allowed characters rather then listing terminating characters. In c or fortran or most other programming languages abc+xyz*rst would be three variable tokens separated by the operator tokens + and * so it is hardly uncommon.

Unlike those languages though, almost none of the lexical rules in TeX are fixed so if you want to allow + and * in multi-letter command names you just need

\catcode`\*=11 \catcode`\+=11

and you can then define \foo*+ as a command, however \alpha+\beta would no longer work you would have to do \alpha +\beta.

It isn't really accurate to say

\mycs* are actually two tokens with the * being the first "argument" to \mycs (even when \mycs isn't defined as taking an argument.

the * isn't (in general) an argument to \mycs it is simply the next token in the output stream, conside \alpha*\beta where the * is simply typeset as an infix operator between the tokens.

  • You can use double backticks if you need a backtick in your inline code ;)
    – yo'
    Feb 26, 2013 at 13:00
  • @tohecz tried that but it came out doubled, switched to display form:-) Feb 26, 2013 at 13:03
  • You are right, I am not really interested in the terminating characters, but rather why so few characters are allowed in easily used command sequences.
    – StrongBad
    Feb 26, 2013 at 14:39
  • One should note that allowing digits in command names by making them category code 11 will break many other TeX constructs that expect digits to have category code 12.
    – egreg
    Feb 26, 2013 at 14:40
  • @egreg Yes if you make digits catcode11 then most things break Feb 26, 2013 at 14:49

Observe the behaviour of the following things:

If * was a part of the name of the macros, then necessarily $\alpha*\beta$ leads to Undefined control sequence: \alpha*, which is not what people expect.

You can of course use e.g. x instead of *, but I like the way how it is: \section and \section*, and not \section and \sectionx.

On the input stream, a sequence of characters is converted to a command sequence if it is an escape character (\ by default) followed by at least one letter character (a-zA-z by default, @ in some places, _ and : in expl3 syntax; in general any character can "be made a letter"). You can have macro names containing non-letters, but you cannot call them directly, you have to use \csname...\endcsname.


There is an answer or comment, somewhere on this site, by Andrew Stacey to the effect that TeX has weird code syntax because the language is designed to disappear into the text of the document. In the case of macros, this is literally true, as they expand and vanish, but in the case of macro names it should be equally true that the code parser is conservative enough not to mangle the text while executing. Particularly since TeX was designed with mathematics in mind, it seems quite reasonable that any special symbol should be reserved for semantic use by the author, not syntactic use by the programmer. Indications are that Knuth considered the macro language to be a supporting feature, rather than the main activity of writing in TeX. For that reason, it is understandable that it is easier to write lazy but correct text than it is to write lazy but correct TeX.

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.