True, but consider that Forth and Lisp started out as interpreted languages, meaning the whole thing can be done at compile time. I haven't seen this feature before in a language that was designed to be compiled to machine code, such as C, Pascal, Fortran, etc.
BTW, D's ImportC C compiler does CTFE, too!! CTFE is a natural fit for C, and works like a champ. Standard C should embrace it.
"Steve Russell said, look, why don't I program this eval ... and I said to him, ho, ho, you're confusing theory with practice, this eval is intended for reading, not for computing. But he went ahead and did it. That is, he compiled the eval in my paper into IBM 704 machine code, fixing bugs, and then advertised this as a Lisp interpreter, which it certainly was. So at that point Lisp had essentially the form that it has today”
Steve Russell comment is about writing the actual interpreter for Lisp, so the comment is correct on that Lisp started out as an interpreted language, and even mentions that in the comment that you quote.
The interpreter (i.e. Lisp READ-EVAL-PRINT loop) was written in IBM 704 machine code, which just was a reimplementation of the EVAL function as JMC described it in his paper.
The part that "wasn't supposed to be implemented" was about the form of Lisp, M-expressions vs. S-expressions not Lisp it self. Which was supposed to be implemented as a programming system from day one.
BTW, D's ImportC C compiler does CTFE, too!! CTFE is a natural fit for C, and works like a champ. Standard C should embrace it.