''[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