[Tex/LaTex] Why using a backslash in command definitions

etoolboxmacrosxparse

I want to know the reasoning behind the (La)TeX inferface for defining commands with leading backslashes. I see why a backslash has to be used to call (expand) a command (macro), but I do not understand why it is used in definitions.

There are many ways to define a command in (La)Tex (ignoring the \let commands and the LaTeX 3 core and possible others) giving the command name with a leading backslash:

TeX: \def, \gdef, \edef and xdef, all having possibly the prefix \long
LaTeX: \newcommand, \renewcommand, providecommand, DeclareRobustCommand, all having possibly the suffix *
etoolbox: \newrobustcommand, \renewrobustcommand, providerobustcommand, all having possibly the suffix *
xparse: \DeclareDocumentCommand, \NewDocumentCommand, \RenewDocumentCommand, \ProvideDocumentCommand, all having possibly an + in the argument specification

There is also the possibility to define a command without a backlash

TeX: \expandafter\def\csname name \endcsname (similar for the commands mentioned for TeX above)
etoolbox: \csdef (similar for the commands mentioned for TeX above)

I think the definitions without a backslash have clear advantages:

more general: allowing to create dynamically named commands (e.g. \csdef{double#1}{#1,#1})
better semantic: The backslash means using a variable, i.e. expanding it
shorter: Save one character, do not disturb the eye

The question is: Why do the default command definitions need a backlash when it seems more useful to do without?

Specifiying the question a bit more:
Obviously, the definitions from etoolbox have advantages compared to the TeX ones being much shorter and clearer. The xparse definitions have clear advantages regarding their arguments' flexibility, too. So it seems natural to combine them. If one would define (with \expandnext from etextools) a command like

\NewDocumentCommand{\declare}{mmm}{%
    \expandnext{\DeclareDocumentCommand}{\csname #1\endcsname}{#2}{#3}%
}

what would one loose? Let us assume, that new, renew and provide would be defined similarly and let us keep the local/global discussion and the possible expansion of the third argument aside, leading to \gdeclare, \edeclare and xdeclare in the long run.

Best Answer

There are a few reasons why defining document commands has always been done using the control sequence for the command (\foo) rather than the control sequence name (foo). Of course, some of this comes down to 'you'd have to ask Leslie Lamport or Don Knuth', as it follows from the TeX basics. (For example, \newcommand\foo mirrors \def\foo, and \DeclareDocumentCommand\foo mirrors \cs_new:Npn \foo.)

First, there is an intrinsic consistency for requiring that the 'appearance' at the point of definition is the same as that at point of use.

Secondly, requiring that a token is construction avoids confusion about what can usually appear in a command name. For example, if you did

\declare{foo-bar}...

\foo-bar

the latter would not work (assuming standard LaTeX category codes) as TeX would 'see' the token \foo followed by a hyphen and the letters b, a and r. That looks like a good way to have problems.

Third, the current set up allows 'experts' to skip the { ... } pair

\newcommand\foo{definition}

works in the same way as

\newcommand{\foo}{definition}

something that was important when TeX was 'smaller' (we save two tokens there), but also something that many people find easier to read. (Moreover, as most good editors highlight LaTeX tokens differently from 'running text', using a token-based approach works better with many editors.)

Related to that, you have to remember that the current interface was designed in the 1980s based on a system developed in the late 1970s. The additional work for both \csname expansion and storage of tokens (separate letters rather than a control sequence) was much more important in the past than it is today.

Finally, if you look at the LaTeX3 stuff we want to avoid 'dynamic' definitions as far as possible at the document interface level. One of the lessons of LaTeX2.09/LaTeX2e is that a clearly defined interface is a good thing: encouraging the use of dynamic names does not help there.

Related Solutions

Macros – Common Features of All Starred Commands in LaTeX

Why do we give commands names? To indicate, ideally as clearly as possible, what it is that they do.

If you have two things that do very similar things, it makes sense to give them very similar names. On the other hand, if they do one thing significantly differently, you would like to be able to easily tell the two names apart, despite those names being similar. As an asterisk is a non-alphabetical character, and fairly dense, it stands out. It is therefore a reasonable way to modify the name of one command, to obtain a similar but easily distinguished command name.

But no, there isn't anything which all starred variants have in common. The command \section*, the amsthm command \newtheorem*, and the amsmath environment align* are un-numbered variants of their un-starred cousins. However:

\newcommand* creates a macro which will not accept carriage returns in any of its arguments.
\vspace* adds vertical space which will not be suppressed at the beginning or end of a page.
\\* creates a new line which will not cause a page break.
\tag* (in amsmath) allows you to add a visual label, comment, or other number-replacement for an equation, without the usual parentheses.

There is a bit of a theme of negation here, but it's not clear that these negations are of anything in common (aside, trivially, from "default" behaviours).

Macros – Why Isn’t Everything Expandable in TeX?

While a definitive answer can only come from the Stanford team involved in development of TeX, and from Professor Knuth in particular, I think we can see some possible reasons.

First, Knuth designed TeX primarily to solve a particular problem (typesetting The Art of Computer Programming). He made TeX sufficiently powerful to solve the typesetting problems he faced, plus the more general case he decided to address. However, he also kept TeX (almost) as simple as necessary to achieve this. While expandable macros are useful, they are not required to solve many issues.

Secondly, there are cases where an expandable approach would be at least potentially ambiguous. Bruno's \edef\foo{\def\foo{abc}} is a good case. I'd say that here the expected result with an expandable \def is that \foo expands to nothing, but I'd also say this is not totally clear. There is the much more common case where you want something like

\begingroup
\edef\x{%
 \endgroup
 \def\noexpand\foo{\csname some-macro-to-fully-expand\endcsname}%
 }
 \x

which would be made more complex with expandable primitives.

The above example points to another grey area: what would happen about things like \begingroup and more importantly \relax. The fact that the later is a non-expandable no-op is often important in TeX programming. (Indeed, the fact that \numexpr, etc., gobble an optional trailing \relax is sometimes regarded as a bad thing.)

Finally, I suspect that ease of implementation is important. The approach of having separate expansion and execution steps makes the flow relatively easy to understand, and I also suspect to implement. An approach which mixes expansion and execution requires a more complex architecture. Here, we have to remember when Knuth was writing TeX, and the fact that programming ideas which we take for granted today were not necessarily applicable in the late 1970s. A fully-expandable approach would I suspect have made the code more complex and slower. The speed impact is one that was important when TeX was running on 'big' computers.

Best Answer

Related Solutions

Macros – Common Features of All Starred Commands in LaTeX

Macros – Why Isn’t Everything Expandable in TeX?

Related Question