Homoiconic refers to parts of a program (such as functions) being stored in source code form (or some tokenized form close to source code). This was coined in the TRAC project in the 1960's. homo = same, icon = representation.
The POSIX shell is homoiconic because you can list the function definitions, and copy and paste them to redefine them. (Similarly to how the TRAC language supposedly allowed definitions to be recalled an edited.)
ANSI Common Lisp has an optional feature for obtaining the definition of a function in textual form. For that to work, the implementation has to waste space retaining that info when a function is compiled.
Related to that feature is a function called ed for editing a function with a resident editor.
Compiled Lisps that don't retain the function source code are definitely not homoiconic.
That source-code-being-data property of Lisp with application-defined code manipulation before code is interpreted or compiled is something other than "homoiconic".
"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."
"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"
This means that interpreted Lisp source is "homoiconic". Compiled Lisp code with stored source code would not be "homoiconic".
Exactly. But the "code-is-data" processing in Lisp mistakenly conflated with homoiconic does not depend on Lisp being interpreted. That interpreted Lisp is homoiconic is of no consequence. It's nothing worth implementing elsewhere.
Homoiconicity is just a poorly optimized, simple language implementation technique for low-resource systems. (Low resource because if you keep the program definitions in the program run-time, you don't need a separate copy in a text editor, which would take up more RAM. This is why old-fashioned line-number BASIC is homoiconic.)
Today, we have no need for it. For values of today being the last 30-40 years.
Source code is kept in the buffers of an IDE; there is no need to have it squirreled away in the run-time. A running image can load compiled code; the goal of redefining the program while it is active doesn't require homoiconicity.
Your opinion is fringe. Here is a quote from wiki:
"In computer programming, homoiconicity (from the Greek words homo- meaning "the same" and icon meaning "representation") is a property of some programming languages. A language is homoiconic if a program written in it can be manipulated as data using the language.[1] The program's internal representation can thus be inferred just by reading the program itself. This property is often summarized by saying that the language treats code as data."
Comments
Homoiconic refers to parts of a program (such as functions) being stored in source code form (or some tokenized form close to source code). This was coined in the TRAC project in the 1960's. homo = same, icon = representation.
The POSIX shell is homoiconic because you can list the function definitions, and copy and paste them to redefine them. (Similarly to how the TRAC language supposedly allowed definitions to be recalled an edited.)
ANSI Common Lisp has an optional feature for obtaining the definition of a function in textual form. For that to work, the implementation has to waste space retaining that info when a function is compiled.
Related to that feature is a function called ed for editing a function with a resident editor.
Compiled Lisps that don't retain the function source code are definitely not homoiconic.
That source-code-being-data property of Lisp with application-defined code manipulation before code is interpreted or compiled is something other than "homoiconic".
Wikipedia cites a TRAC article:
"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."
This means that interpreted Lisp source is "homoiconic". Compiled Lisp code with stored source code would not be "homoiconic".
Exactly. But the "code-is-data" processing in Lisp mistakenly conflated with homoiconic does not depend on Lisp being interpreted. That interpreted Lisp is homoiconic is of no consequence. It's nothing worth implementing elsewhere.
Homoiconicity is just a poorly optimized, simple language implementation technique for low-resource systems. (Low resource because if you keep the program definitions in the program run-time, you don't need a separate copy in a text editor, which would take up more RAM. This is why old-fashioned line-number BASIC is homoiconic.)
Today, we have no need for it. For values of today being the last 30-40 years.
Source code is kept in the buffers of an IDE; there is no need to have it squirreled away in the run-time. A running image can load compiled code; the goal of redefining the program while it is active doesn't require homoiconicity.
Your opinion is fringe. Here is a quote from wiki: "In computer programming, homoiconicity (from the Greek words homo- meaning "the same" and icon meaning "representation") is a property of some programming languages. A language is homoiconic if a program written in it can be manipulated as data using the language.[1] The program's internal representation can thus be inferred just by reading the program itself. This property is often summarized by saying that the language treats code as data."