Definition Of Homoiconic

homoiconic: Same representation of code and data, from homo meaning the same and icon meaning representation (DougMcIlroy & C.S.Peirce 1960, PeterDeutsch & CalvinMooers 1965, AlanKay, 1969).

The original source, according to the early and influential paper "TRAC, A Text-Handling Language" (TracLanguage), by C. N. Mooers and L. P. Deutsch (1965) [http://tracfoundation.org/trac64/handling.htm], was the paper MacroInstructionExtensionsOfCompilerLanguages?:

: One of the main design goals was that the input script of TRAC (what is typed in by the user) should be identical to the text which guides the internal action of the TRAC processor. In other words, TRAC procedures should be stored in memory as a string of characters exactly as the user typed them at the keyboard. If the TRAC procedures themselves evolve new procedures, these new procedures should also be stated in the same script. The TRAC processor in its action interprets this script as its program. In other words, the TRAC translator program (the processor) effectively converts the computer into a new computer with a new program language -- the TRAC language. At any time, it should be possible to display program or procedural information in the same form as the TRAC processor will act upon it during its execution. It is desirable that the internal character code representation be identical to, or very similar to, the external code representation. In the present TRAC implementation, the internal character representation is based upon ASCII (American Standard Code for Information Interchange). Because TRAC procedures and text have the same representation inside and outside the processor, the term homoiconic is applicable, from homo meaning the same, and icon meaning representation.
: [...]
: Following suggestion of McCullough, W. S., based upon terminology due to Peirce, C. S. s McIlroy. M. D., "Macro Instruction Extensions of Compiler Languages," Comm. ACM, p. 214?220; April, 1960.

AlanKay used and possibly popularized the term "homoiconic"; he used it in his 1969 PhD thesis [http://www.mprove.de/diplom/gui/kay69.html]:

: A notable group of exceptions to all the previous systems are Interactive LISP [...] and TRAC. Both are functionally oriented (one list, the other string), both talk to the user with one language, and 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's pleasure.
: Their only great drawback is that programs written in them look like King Burniburiach’s letter to the Sumerians done in Babylonian cuniform! [...]

Please note that the language definition specifies that they have the same representation (not merely the implementation of the language, and not merely some code written in the language); the code is in all ways FirstClass.

Note this implies that, ideally, compiling a normally-interpreted homoiconic language should not change the fact that it is homoiconic -- the compilation should be transparent. If transparency is violated by compilation, then in effect, a new dialect of the language is created which might not be homoiconic, even if its parent language were indeed homoiconic (homoiconicity inherently implies interpretive semantics, which are possible, if not common, to implement in a compiled implementation)

Notably contradicted:

Reflectiveness, by itself, does not imply homoiconicity.
Lazy evaluation, by itself, does not imply homoiconicity (although the other characteristics do imply an ability to do lazy evaluation, e.g. in writing a function that behaves like if).
Bootstrapping a language implementation in itself does not imply homoiconicity.
Having some metacircular implementation features, such as "\n", does not imply homoiconicity (but HomoiconicLanguages have the ability to easily write a MetaCircularEvaluator implementation -- which, note, is not just writing a language in itself).

There is some debate about what exactly constitutes homoiconicity, and about which languages are homoiconic (HomoiconicityClassification). See for instance the HomoiconicFaq, or search on 'homoiconic':

: "homoiconic programming languages, are languages where code and data have the same representation. An example is Common Lisp, and Scheme, where data and code are lists, another one is Tcl where data and code are both strings." -- http://wiki.hping.org/127

Since this definition is considerably fuzzy, due in part to the evolution of languages in the last 4 decades, an unambiguous alternative has been proposed HomoiconicDefinitionTakeFive.

Discussion moved to DefinitionOfHomoiconicDiscussion

See HomoiconicLanguages, HomoiconicityAdvantages, HomoiconicLanguageDrawbacks