Necessity of braces when creating newcommand using csname

Question

Why does \expandafter\newcommand\csname hello\endcsname{Hello world} create a new macro while \expandafter\newcommand{\csname hello\endcsname}{Hello world} creates garbage?

Form what I understand, \csname hello\endcsname programatically creates a new string that can be used as a command name, in this case, something like \hello. You can write both \newcommand\hello{Hello world} and \newcommand{\hello}{Hello world} and they both work. So why is it that when csname is envolved, I have to use the form without curly braces surrounding the name?

Answer 1

The “official” syntax for \newcommand is

\newcommand{<macro name>}[<args>]{<text>}

or

\newcommand{<macro name>}[<args>][<default>]{<text>}

but it turns out that the braces around the <macro name> are optional, so long as a single token appears. The braces are good for avoiding mistakes, but some self-control usually suffices.

With

\expandafter\newcommand\csname hello\endcsname{world}

the token \hello is built before \newcommand starts acting and absorbing its first argument (the story is much longer, actually, but this short explanation is precise enough).

On the other hand,

\expandafter\newcommand{\csname hello\endcsname}{world}

will try to expand the brace: \expandafter just acts on a single token, triggering its expansion, if the token is expandable, otherwise doing nothing. You can have the braces, if you prefer, but you need a further \expandafter:

\expandafter\newcommand\expandafter{\csname hello\endcsname}{world}

However this is too much for such a simple construction, isn't it?

If you find yourself in the position of having to do several of these definitions, it's “easy” to build a wrapper

\makeatletter
\newcommand\newnamecommand{\@star@or@long\new@name@command}
\newcommand\new@name@command[1]{\expandafter\new@command\csname #1\endcsname}
\newcommand\renewnamecommand{\@star@or@long\renew@name@command}
\newcommand\renew@name@command[1]{\expandafter\renew@command\csname #1\endcsname}
\newcommand\providenamecommand{\@star@or@long\provide@name@command}
\newcommand\provide@name@command[1]{\expandafter\provide@command\csname #1\endcsname}
\makeatother

\newnamecommand{hello}{Hello World}
\newnamecommand*{helloarg}[1]{Hello #1}

\renewnamecommand{hello}{Whatever}

\providenamecommand{foo}{FOO}

Answer 2

You need to supply an explicit control sequence for \newcommand, and \csname <text>\endcsname is not a control sequence until it is expanded.

Using

\expandafter\newcommand\csname hello\endcsname{<stuff>}

expands to

\newcommand\hello{<stuff>}

as a result of the \expandafter skipping over \newcommand and expanding \csname hello\endcsname to \hello. However,

\expandafter\newcommand{\csname hello\endcsname}{<stuff>}

expands to

\newcommand{\csname hello\endcsname}{<stuff>}

as { is not expandable, making \expandafter useless. If you want to use the "grouped interface for \newcommand", you would need an additional \expandafter:

\expandafter\newcommand\expandafter{\csname hello\endcsname}{<stuff>}

However, without it, \newcommand fails since there's no explicit control sequence.

etoolbox provides a means around this via an interface to \@namedef{<csname>} (from the LaTeX kernel latex.ltx):

\csdef{<csname>}<args>{<stuff>}

That is, you can use

\csdef{hello}<args>{<stuff>}

<args> above are optional but take the \def form of argument specification (or pattern). That is, #1 instead of [1], say.