13

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.

Improve this question

2 Answers 2

Reset to default
16

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.

Improve this answer
5
  • Thanks for this great answer, although I do not agree with all decisions taken decades ago.
    – Patrick Häcker
    May 28, 2012 at 13:14
  • @MMM As I say, tokens were very important and dictated some decisions. For example, LaTeX2e was very tight with the then-current emTeX system, and I believe the team spent some time removing unneeded tokens for this reason. See for example the use of things like \@ne or \@ht, which make for hard-to-read code but help save space.
    – Joseph Wright ♦
    May 28, 2012 at 13:18
  • First: I see the point, but I think the backslash-means-using-consistency is also a good thing. Second: This name could be used with \csuse. If not, both result in an error, either at define-time or at expand-time (with the important exception that the behaviour would be wrong if \foo existed). Third: Highlighting seems to be a similar effort with regular expressions. Skipping the {...} might nowadays being a matter of taste (consistency vs. conciseness). Thanks again!
    – Patrick Häcker
    May 28, 2012 at 13:25
  • Yes, this has definitely been important. My wording was misleading: I am not completely happy that we still have to live with things that might be unimportant today reducing the readability only for historical reasons. Implementing some caching or multi-threading today would earn us much more than these little things, ideally without reducing the readability. But I know it is hard and did not want to sound ungrateful. Thanks for all your hard work, I am looking forward to LaTeX 3.
    – Patrick Häcker
    May 28, 2012 at 13:32
  • I don't understand what you mean "avoid dynamic definitions at document interface level" for LaTeX3. Could you elaborate?
    – Aditya
    May 28, 2012 at 14:11
3

You're free to define, more simply,

\def\NewDocumentCommandName#1{%
  \expandafter\NewDocumentCommand\csname #1\endcsname}

and then say

\NewDocumentCommandName{foo}{mm}{Whatever with #1 and #2}

if you prefer so. But this is no clearer than

\NewDocumentCommand{\foo}{mm}{Whatever with #1 and #2}

and I don't see a clear syntax for "dynamically defined commands".

The distinction between "definition" and "use" of a variable is maintained in Unix shells, where foo=bar assigns the meaning and $foo delivers the value. There are reasons for this. Not in TeX, in my opinion, as in many other programming languages.

Improve this answer
6
  • The advantage of the former is that you can use it for nested definitions: \NewDocumentCommandName{defineenvironment}{m}{\NewDocumentCommandName{start#1}{whatever}\NewDocumentCommandName{stop#1}{whatever}} etc.
    – Aditya
    May 28, 2012 at 14:12
  • @Aditya I don't see great advantages in doing this: passing arguments to the newly defined commands would be difficult and quite rarely one has pairs of commands of the form \startfoo and \stopfoo (with variable suffix) that are all defined similarly.
    – egreg
    May 28, 2012 at 14:24
  • ConTeXt does this all the time: \define<something> usually defines \start<something> \setup<something>, etc (actually, it defines multi-lingual macros, so in french documents you can use \demarre<something> .. \regale<something>. Internally, all such macros use \setvalue (or its variants \setuvalue, etc), which are similar to the \NewDocumentCommandName macro (actually to \@namedef etc.)
    – Aditya
    May 28, 2012 at 15:22
  • Compare the above from, say the plainTeX definition of \newif\ifsomething which then goes through some hoops to remove the \if and define \somethingtrue, \somethingfalse. Using \newconditional {something} would be much easier.
    – Aditya
    May 28, 2012 at 15:25
  • I am still not used to this form of partial function application. Thanks for reminding me.
    – Patrick Häcker
    May 28, 2012 at 15:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .