4 ms·
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 ac
by lispm 3y ago
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."
> "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".
- kazinator 3y agoExactly. 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.