[velis_vel]

Right, but it seems inaccurate to me to say that Lisp code 'has no syntax'. What do you call the reason that 2927(foo"bar. isn't a valid Lisp program?

Alternately: If I augment Python by letting you surround a block of Python code with curly braces in order to get an object representing the corresponding AST, does that mean that I can write Python directly in parse trees? :P

[Chattered]

It's always called a "read" error. If you're working at the REPL, it's detected at the Read phase of the Read-Eval-Print-Loop. It is, of course, a read-syntax error.

But the fact that the Read phase can be usefully separated from the Eval phase is a distinguishing feature of Lisp, and why it makes sense to say, at least, that Lisp has no concrete syntax, only abstract syntax. Lisp programmers fluently think in terms of the abstract syntax their code generates, because they read and write in the string representation of that abstract syntax. That's why it makes sense for the Lisp eval function, unlike the eval function in other dynamic languages, to take lists as input rather than strings. That's why a metacircular interpreter in Lisp will be written to input lists. That's why a DSL in Lisp written as a custom evaluation function will be an interpreter for lists. The Lisp language is defined with respect to the list data-structure, rather than strings.

On your Python idea: the problem is that no-one would ever use Python code as the literal representation of Python's abstract syntax.

It would be entirely backward, anyway. Lisp starts as a notation for a data-structure rich enough to represent abstract syntax (symbolic expressions) and then defines a language in terms of this data structure. The philosophy of this is understood when we realise that the roots of Lisp are in metalanguages and logic.