[zaphar]

It's about ergonomics. Technically if I'm willing to grab a library to parse the AST and hook into the compiler/interpreter backend then I can replicate what Lisp let's me do in any language that exists. But there is a pretty wide gap between how easy that is in say... C++ as opposed to Lisp. Some languages get a lot closer than others but I would argue that with the exception of Forth or perhaps TCL none of them make it anywhere near as easy Lisp does.

[int_19h]

The line between "language" and "library" can be very blurry - it certainly is in case of Lisp.

Suppose we take something like Python, which has a standard library module to parse ASTs, modify them, and eval them. It might look a tad more ugly than Lisp (esp. with quoting and unquoting), but I don't see why this should be considered a fundamental difference, enough so to justify its use as the sole determining factor of a "true Lisp".

And besides, what about popular languages that do have full-fledged macros? Say, Rust or D.

[zaphar]

The point is still about ergonomics though. The AST for Rust or D is still complicated enough that you typically won't do the kind of thing you might do in a lisp just due to startup cost. Lisp because of it's extremely limited syntax makes it considerably easier. The sorts of things you'll feel free and capable of doing in a lisp macro are ergonomically harder to do in a Rust or D macro.

You might argue, quite convincingly, that Rust and D have valuable ergonomic barriers to doing some of those things since macros have a non-trivial cost in your codebase regarding complexity and readaiblity. But the ergonomics of a macro is Lisp are pretty close to the optimal for ease of use.