My Naive Attempt At Understanding Homoiconicity

[From NewAttemptedHomoiconicDefinition]

As I understand it, because the source and the data are represented the same way, homoiconicity makes it possible to

assign a bit of code to a variable
modify it, in the same way other variables can be modified
execute it

In doing so, we are switching between code-mode and data-mode (except, of course, we are not really switching, since there is no real difference). Reflection is switching from code-mode to data-mode. Dynamic code generation is switching from data-mode to code-mode. But from what I gather from other discussions, true homoiconicity seems to imply the ability to do this on code that is running, while it is running, making it continue with the modified version.--AalbertTorsius

Yes, but (1) this is an implication of homoiconicity, not a definition thereof, (2) it's not about switching modes, it's about "same representation", (3) there are several kinds of reflection in the world; one common kind is e.g. the ability to list method names, which by itself is rather far from the total reflection that homoiconicity allows; conversely, there are completely reflective languages that have the same reflective abilities as homoiconic languages, but which are not homoiconic ("same representation").

Homoiconicity leads to some nice abilities. That's not to say that it's the only way to get those abilities. -- DougMerritt

That's why I said "because the source and the data are represented the same way...". It seems to me that this the major way of finding out whether a language is homoiconic -- iff you can do this, the language is homoiconic. I agree with your third point, about reflection. I added the point about running code, since that's what eval() seems to be all about. Perhaps I should've said "code that's about to run".--ATS

That's a good question about changing the behavior of existing code that is running. I don't see that stated as a requirement in AlanKay's quote (from the NewAttemptedHomoiconicDefinition page) -

AlanKay: "[...] both are 'homoiconic' in that their internal and external representations are essentially the same. They both have the ability to dynamically create new functions which may then be elaborated at the users' pleasure."

If changing the behavior of existing functions/methods/classes that are already loaded is a requirement, then Java 1.4 can't do that directly, you'd need indirection through an interface so that you can change the implementation. But Java 1.5 does support rewriting the byte code implementation of existing loaded and running methods at run time.

Which is handy. But is not the definition of homoiconic; this focuses on the second part of the AlanKay quote while ignoring the first part about same representation. That in itself does not mean that e.g. Java is less powerful than homoiconic languages; facilities such as that are quite powerful. -- DougMerritt

If java would permit something like

  Method fooMethod = this.getClass().getMethod("foo");
  Statement[] fooBody = fooMethod.getBody();
  // in some way, edit fooBody
  // ...
  fooMethod.setBody(fooBody);
  this.getClass().setMethod("foo", fooMethod);

would that make java homoiconic? Nevermind that while running, it is compiled into bytecode; the way a programmer would access it would be through classes, which are FirstClass in java. On the other hand, if modifying the code at runtime would mean loading the bytecode into an array of bytes and then modifying it byte by byte (I admit I don't know how java 1.5 does it), would not imply homoiconicity (to me), even while bytes are FirstClass as well, it's not exactly easy or intuitive.--ATS

Maybe HomoiconicDefinitionTakeFive can help you (and Eric and others who were confused). If the code above would be possible in Java (with some caveats it actually is possible in Java 2), what you'll have is that Java will be fully reflective, but not homoiconic. Incidentally the trick above is not even available in Common Lisp as the language is not fully reflective. Homoiconic and reflective are distinct but related, and in combination they're very powerful (enough rope and all that).

As that definition seems to be heavily disputed (as well), it doesn't really answer my questions, alas.

advantages moved to HomoiconicityAdvantages

EditHint: Merge with HomoiconicFaq