Homoiconicity

In computer programming, homoiconicity is a property of some programming languages, in which the primary representation of programs is also a data structure in a primitive type of the language itself, from "homo" meaning "the same" and "icon" meaning "representation".

History

The original source is the paper "Macro Instruction Extensions of Compiler Languages",Douglas McIlroy (1960) [http://doi.acm.org/10.1145/367177.367223 "Macro Instruction Extensions of Compiler Languages"] ] according to the early and influential paper "TRAC, A Text-Handling Language":Calvin Mooers and L. Peter Deutsch (1965) " [http://doi.acm.org/10.1145/800197.806048 TRAC, A Text-Handling Language] "] quote|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. 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.

Alan Kay used and possibly popularized the term "homoiconic" through his use of the term in his 1969 PhD thesis:Alan Kay (1969) [http://www.mprove.de/diplom/gui/kay69.html "The Reactive Engine", PhD thesis] (Accessed 20061229)] quote|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! [...]

Use and Advantages

One advantage of homoiconicity is that extending the language with new concepts typically becomes simpler, as data representing code can be passed between the meta and base layer of the program. A typical demonstration of homoiconicity is the metacircular interpreter.

Examples

Languages which are considered to be homoiconic include most members of the Lisp family, Prolog, Smalltalk, Curl, REBOL, SNOBOL, XSLT, TRAC, Tcl, Io, Joy, Factor, Clojure, PostScript and V.

In Von Neumann architecture systems (including the vast majority of systems today), raw machine code also has this property, the data type being bytes in memory.

References

See also

* Cognitive dimensions, design principles for programming languages.

External links

* [http://c2.com/cgi/wiki?DefinitionOfHomoiconic Definition of Homoiconic at the C2 Wiki] . Note that the discussion about the exact definition is still ongoing at this site.