4 ms·

Like most people, I'm going to keep using the word "homoiconic" because it is a useful term. The article just shows that if you insist on an absurdly strict de

Like most people, I'm going to keep using the word "homoiconic" because it is a useful term. The article just shows that if you insist on an absurdly strict definition you end up with nonsense. Even the "strings" based definition doesn't work if you're being especially literal, since there are no strings, there are just electrical fields that may or may not be in physically nearby places. Everything in software is, at some level, an abstraction. And that's okay. S-expressions are merely a textual representation; Lisp systems don't normally store exactly the text representation. So what? The upshot is that homoiconic representations make certain kinds of transformations easy to use, understand, and display... and that's what people mean today. I agree that homoiconicity is not strictly boolean, but that doesn't make it a useless concept.

dmix 7y ago
In language as long as the other people know what you mean it's totally fine. Context is all that matters. It's only a problem if there was already a meaningful term closely related to what you mean and you're simply using incorrectly which might confuse people. In that case it's okay to challenge the word use. Otherwise I never understood some people's obsession with not reusing words in new places. Other than to be "right" about something. It's then really only useful as a historical look at the term.
- kazinator 7y ago
  There is a single context for the (ab)use of "homoiconic": the context of classifying programming languages/features. Now, of course, there can be smaller subcontext contexts, like "Bob's paper about classifying programming languages". In such a thing, Bob can define black to be white, if Bob wants; however, that definition ends when we turn over the last page of Bob's paper and return to reality.
rosser 7y ago
> The article just shows that if you insist on an absurdly strict definition you end up with nonsense. I've sometimes caricatured this kind of argument as: 1. "Blue" is Pantone™ 292. 2. The sky is not Pantone™ 292. 3. Therefore, the sky is not blue.
kazinator 7y ago
I have no idea what it means. You have to buy the 1960 paper "Macro instruction extensions of compiler languages" from Doug McIlroy to learn the exact definition; I can't find a free copy anywhere online. Since the word was born with a definition, we should respect that rather than inventing one. Note that Lisp systems don't necessarily store any representation at all, other than compiled code. To work with the source code, you have to intercept it while it is passing through compile time. Intercepting a representation of the code at compile time can be done with technology on the level of the C preprocessor. If that is homoiconic, then C is homoiconic. Quite possibly, McIlroy's definition will in fact cover that. GNU Bash meets the "homoiconic" definition that the TRAC authors adopted. At any time, you can type the "set" command to view the definitions of all functions. They look the way they were entered, modulo reindentation, and stripping of # comments. Homoiconic may continue to be useful; but as a word that possibly extends to low-brow hacks like C preprocessing, it is is not useful for describing the advantages of Lisp and its ilk, that's all.

dmix 7y ago

In language as long as the other people know what you mean it's totally fine. Context is all that matters. It's only a problem if there was already a meaningful term closely related to what you mean and you're simply using incorrectly which might confuse people. In that case it's okay to challenge the word use. Otherwise I never understood some people's obsession with not reusing words in new places. Other than to be "right" about something. It's then really only useful as a historical look at the term.

kazinator 7y ago
There is a single context for the (ab)use of "homoiconic": the context of classifying programming languages/features. Now, of course, there can be smaller subcontext contexts, like "Bob's paper about classifying programming languages". In such a thing, Bob can define black to be white, if Bob wants; however, that definition ends when we turn over the last page of Bob's paper and return to reality.

rosser 7y ago

> The article just shows that if you insist on an absurdly strict definition you end up with nonsense. I've sometimes caricatured this kind of argument as: 1. "Blue" is Pantone™ 292. 2. The sky is not Pantone™ 292. 3. Therefore, the sky is not blue.

kazinator 7y ago

I have no idea what it means. You have to buy the 1960 paper "Macro instruction extensions of compiler languages" from Doug McIlroy to learn the exact definition; I can't find a free copy anywhere online. Since the word was born with a definition, we should respect that rather than inventing one. Note that Lisp systems don't necessarily store any representation at all, other than compiled code. To work with the source code, you have to intercept it while it is passing through compile time. Intercepting a representation of the code at compile time can be done with technology on the level of the C preprocessor. If that is homoiconic, then C is homoiconic. Quite possibly, McIlroy's definition will in fact cover that. GNU Bash meets the "homoiconic" definition that the TRAC authors adopted. At any time, you can type the "set" command to view the definitions of all functions. They look the way they were entered, modulo reindentation, and stripping of # comments. Homoiconic may continue to be useful; but as a word that possibly extends to low-brow hacks like C preprocessing, it is is not useful for describing the advantages of Lisp and its ilk, that's all.