By definition the word homoiconic means:
Same representation of code and data
In LISP this means that you could have a quoted list and evaluate it, so (car list) would be the function and (cdr list) the arguments. This can either happen at compile- or at run-time, however it requires an interpreter.
Is it possible that compiled languages without a compile-time interpreter can be homoiconic as well? Or is the concept of homoiconicity limited to interpreters?
Seems to me to be an odd question:
Firstly, the homoiconic portion is the presented interface to the programmer. The point of languages is that they abstract a lower level functionality that preserves the same semantics as the higher level presentation (though a different means).
dsm's machine-code point is a good point, but providing:
why does the lower level implementation matter here?
Also:
compiled languages without a compile-time interpreter
Without some program interpreting it, it would be required to be native to the CPU, therefore the CPU's native language would be required to be homoiconic (or the VM running the code).
Languages without compile-time interpretation ... would be fairly constrained ... as they wouldn't be compiled at all.
But I am no expert, and maybe missing the point.
Languages built on top of VM's (.net clr, jre ect) can use advanced technics that allow on the fly code generation. One of them is IL weaving. Although, its not as clear as eval's of ECMAScript/Lisp/Scheme ect but it can to a some degree emulate such behavior.
For examples check Castle DynamicProxy and for more interactive example check LinqPAD, F# Interactive, Scala interactive.
'Homoiconic' is kind of a vague construct. 'code is data' is a bit clearer.
Anyway, the first sentence on Wikipedia for Homoiconic is not that bad. It says that the language has to have a source representation using its data structures. If we forget 'strings' as source representation (that's trivial and not that helpful to have a useful concept 'homoiconic'), then Lisp has lists, symbols, numbers, strings etc. which are used to represent the source code. The interface of the EVAL function determines what kind of source representation the language is working on. In this case, Lisp, it is not strings. EVAL expects the usual variety of data structures and the evaluation rules of Lisp determine that a string evaluates to itself (and thus will not be interpreted as a program expression, but just string data). A number also evaluates to itself. A list (sin 3.0) is a list of a symbol and a number. The evaluation rules say that this list with a symbol denoting a function as the first object will be evaluated as a function application. There are a few evaluation rules like this for data, special operators, macro applications and function applications. That's it.
To make it clear: in Lisp the function EVAL is defined over Lisp data structures. It expects a data structure, evaluates it according to its evaluation rules and returns a result - again using its data structures.
This matches the definition of homoiconic: source code has a native representation using the data types of Lisp.
Now, the interesting part is this: it does not matter how EVAL is implemented. All that matters is that it accepts the source code using the Lisp data structures, that it executes the code and that it returns a result.
So it is perfectly legal that EVAL uses a compiler.
(EVAL code) = (run (compile-expression code))
That's how several Lisp system work, some don't even have an Interpreter.
So, 'Homoiconic' says that the SOURCE code has a data representation. It does NOT say that at runtime this source code has to be interpreted or that the execution is based on this source code.
If the code is compiled, neither the compiler nor an interpreter is needed at runtime. Those would only be needed if the program wants to eval or compile code at runtime - something that is often not needed.
Lisp also provides a primitive function READ, which translates an external representation (S-Expressions) of data into an internal representation of data (Lisp data). Thus it also can be used to translate an external representation of source code into an internal representation of source code. Lisp does not use a special parser for source code - since code is data, there is only READ.
The problem is that a lot of processors separate instruction and data areas, and actively prevent programs from modifying their own code. This kind of code used to be called "degenerate code", and considered a very Bad Thing.
Interpreters (and VMs) don't have that problem, as they can treat the whole program as data, with the only "code" being the interpreter.
In the most literal form, C is homoiconic. You can get access to the representation of a function using &functionName and execute data using somePtrCastToFnPtr(SomeArgs). However this is at the machine code level and without some kind of library support you will find it very hard to work with. Some kind of embeddable compiler (I seem to remember that LLVM can do this) would make it more practical.
Yes; you just have to stick a copy of the compiler into the language runtime. Chez Scheme is one of the many fine compilers which do just that.
Lisp is normally compiled. There have been implementations with JIT compilers instead of interpreters.
Hence, it is not necessary to have an interpreter (in the sense of "not a compiler") for code-is-data languages.
Machine code itself is homoiconic, so yes.
Data or instructions are just a matter of semantics (and perhaps the segment of memory in which them lie).