Data is code

Hello everybody

Does anybody know about other languages for which data is code and vice versa than just Lisp (and its dialects) and Rebol? Are there any which support or, even better, encourage concurrency? And last but not least, is 'metamorphic' the proper term to refer to the attribute described above?

Thank you very much in advance

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Prolog and Concurrent Prolog

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.

homoiconic languages

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

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.

Postscript

I'm not familiar with Joy, but Postscript uses the same "programs are lists" paradigm. Makes it quite a powerful language to have on a printer.

Multi-Stage Programming

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.

While this is true, lisp, lik

While this is true, lisp, like most functional languages tends to be very pleasant for manipulating datastructures in the way that is necessary when dealing with abstract syntax representations. While still possible in a purely imperative language, it is slightly less pleasant. This is probably why people began to think of it as a lisp thing - lisp was for a long time the predominant functional language.

Well said

I've often thought the same thing, but you wrote it down concisely. Nicely done, Paul.