Weird output of \tracingassigns with \font

Question

Setting \tracingassigns to a positive value causes eTeX to write to the log file (and console when \tracingonline is positive) all assignments it performs. Thus, I would expect the following code to indicate that \foo is changed from undefined to select font cmr10.

\tracingonline=1
\tracingassigns=1
\font\foo=cmr10
\message{But \foo is \meaning\foo!}

However, eTeX reports

{changing \foo=undefined}
{into \foo=select font nullfont}
But \foo is select font cmr10!

Why?

Answer 1

Knuth refers to this mechanism on page 278 of the TeXbook:

\TeX\ takes precautions so that constructions like ‘\chardef\cs=10\cs’ and ‘\font\cs=name\cs’ won't expand the second \cs until the assignments are done.

If you add

\chardef\cs=63

you'll find in the log

{changing \cs=undefined}
{into \cs=\relax}
{changing \cs=\relax}
{into \cs=\char"3F}

However, apparently, the change of meaning from "select font nullfont" to "select font cmr10" is not traced and this might be a bug of e-TeX.

Why is such a precaution necessary? When TeX does

\font\foo=<filename>

it performs expansion on what follows the = sign. If \foo, for some reasons, were already defined as a macro, a code such as

\font\foo=cmr10\foo

would result in a probable disaster. So, first of all, TeX changes the meaning of \foo to an unexpandable token, precisely \nullfont. So, a following \foo token would stop expansion and the real assignment can be performed.

In the case of \chardef\cs=63 we are in the same situation:

\chardef\cs=63\cs

would be disastrous if, say, we had \def\cs{1} before. So TeX first assigns to \cs the meaning of \relax and can perform the assignment without worrying that \cs might be expanded. When TeX reads \cs again, it already has the meaning assigned by \chardef.

Update

This is an e-TeX bug due to one of Don's typical (and at the time valid) optimizations. The eTeX change file implements \tracingassigns by interfacing in the procedure eq_define() in module §277 and the assignment of "nullfont" in §1257 is done using this procedure. However, (and this is Don's way of saving a a few computer cycles :-) the second assignment is done through a direct call to the procedure equiv() which is normally not used for assignments as it only changes a pointer but doesn't set the "type" (which is of course still "selectfont").