I understand what you're saying. What I mean is not the trivial "nand is turing complete" sense, which I agree is harmful and silly, but full eval capabilities. Lisp macros can fully evaluate Lisp code, and I consider this a great feature, but I don't know how else to describe them. "Full evaluation macros"?
To my mind, having eval available is a cheap way to make sure you are sufficiently powerful. In principle, it's not the best way. In practice, it's arguably the best way out of options at hand, though some alternatives compete.
> What I mean is not the trivial "nand is turing complete" sense, which I agree is harmful and silly, but full eval capabilities.
The two are equivalent (provided that the target language that can be evaluated is itself turing complete) -- that's rather the nature of turing completeness. If you have the former, you can make the latter with it and nothing else; if you have the latter, you necessarily also have the former.
Yes, it was a poor choice of terms. To be clear, eval isn't equivalent except within the narrow theoretical notion of turing completeness: it can do I/O, for instance file I/O. And it accepts high-level language code directly which is very important in a practical sense compared to, say, accepting nand instructions only.
It's hard to describe because even "full access to the language at compile time" would be useless if that language were C++. The advantage of macros is that you have access specifically to Lisp at compile time, not just any old blub language. And that just circles back to "Lisp is great". :)
