Lambda the Ultimate

Prolog clauses are terms and vice versa. Writing Prolog programs to manipulate Prolog programs is an old tradition. Self-modifying code is easy to write in Prolog using assert and retract. But Prolog is not concurrent.

There is a large family of concurrent logic languages with a syntax that resembles Prolog: Concurrent Prolog, Flat Concurrent Prolog, Guarded Horn Clauses, Flat Guarded Horn Clauses, and many others including AKL, the direct ancestor of Oz. Strand is a nice one designed by Ian Foster for parallel execution (Ian Foster is now one of the main people behind the Grid). But concurrent logic languages are not so popular nowadays.

Data is code is one ability I'd like to see Oz regain, so that we can experiment more easily with linguistic abstractions.

I think this is the right term.
One that comes to mind is Tcl, and it has support for threading but I think it was added somewhat recently (considering that Tcl has been around for a long time).

Joy is a pretty neat little language. A pure functional FORTH. Programs are lists and concatenation is function composition. No concurrency support though, as far as I am aware.

To the extent that the only difference between data and code anyway is that data "only" exists at runtime, whereas code "only" exists at interpret/compile time, any multi-stage language qualifies.

Backing up a step, I've always found the claim that in Lisp "code is data and data is code" to be extremely misleading: if you force your programmer to write in your language's native abstract syntax tree format, of course code is data and data is code, and of course it's obvious what quotation and antiquotation looks like. And unless you use eval there's still a phase distinction keeping them apart. But that doesn't at all preclude the existence of compiler systems that are broken down in such a way that the programmer can extend or replace the parser and generate their own, customzed abstract syntax tree for the compiler to chew on, complete with quotations and antiquotations, but with an Algol-derived surface syntax. Granted, not a lot of languages have done this, but O'Caml did with camlp4, and it works very, very well. In fact, camlp4 is more featureful than Lisp macros if for no other reason than that you can implement a custom printer that produces code in a language other than O'Caml, as Graydon Hoare did in his One-Day Compilers presentation. That is, with camlp4, it's easy to create an X-to-Y transformer that has all of the power of O'Caml available to it.

So this incessant harping on data-as-code and code-as-data in Lisp merely obscures the fact that data is code and code is data in computing. That's the lesson of Lisp, but unfortunately it's gotten lost in the Lisp dogma. One more reason that I don't consider myself a member of the Lisp community, really, anymore, despite some very kind words to the contrary from Peter Norvig.