4 ms·

"... the original definition: languages which have the same external and internal representations are homoiconic." I would re-phrase that as: "Languages whos

"... the original definition: languages which have the same external and internal representations are homoiconic." I would re-phrase that as: "Languages whose external and internal representations of their programs are (to a great degree) ISOMORPHIC, are, and should be, called homoiconic." What does "iconicity" mean? It means isomorphism, meaning the structure of two things are similar, one can be taken to be a picture, an "icon" of the other. Lisp clearly has this property. It is clearly homo-iconic. And most importantly most other languages do NOT have this property. Therefore "homo-iconic" is a very useful property which can be easily used to divide programming languages into two groups, those that are and those that aren't. The original definition is bad: "which have the SAME external and internal representations". "Sameness" is not what homo-iconicity is about. It is about the structures of the external and internal representation being SIMILAR enough that one of them could be considered an ICON, a PICTURE of the other. Perhaps we should stop using words like "similar" as well? They are not "boolean" are they? Clearly 'homo-iconic" has a sound well-founded meaning, even if not everybody gets it. It is a subtle concept similar to understanding why something can be used as a metaphor for another thing. Not everybody gets metaphors either.

kazinator 7y ago
> Lisp clearly has this property. It is clearly homo-iconic. Firstly "Lisp" is a language family; which member are you talking about? ANSI Common Lisp only hints at a form of homoiconicity, but leaves all of it implementation-defined. Namely, the function ed: http://clhs.lisp.se/Body/f_ed.htm http://clhs.lisp.se/Body/f_ed.htm A Lisp implementation which compiles everything and throws away the source will not support function editing with ed. Compiled functions are not similar to the source; they cannot be edited as source and recompiled. I haven't heard of anyone organizing their Lisp workflow around an ed function, which would then count as relying on homoiconicity. Bash is homoiconic: the set command with no arguments dumps out all function definitions, which are reformatted as text from a tokenized form. There isn't a nice feature to edit a function though, other than copying and pasting out of the output of set, or else recalling the original definition in the history. Speaking of which, interactive environments, including command lines with history recall, provide a form of homoiconicity. The command histories or integrated edit buffers hold functions in their original form, allowing them to be edited and redefined. (But those stored forms are outside of the language; they are not the function definitions themselves. It's not the language per se being homoiconic.) When people say "Lisp is homoiconic", they are certainly not talking about the obscure ed function in ANSI CL. Well, that's what they're not talking about. What they are talking about is anyone's guess, but probably they are using the wrong term for the concept of a language being written in terms of a generic tree data structure that expresses all possible syntax tree shapes, and which is manipulable in that language.
- galaxyLogic 7y ago
  If a Lisp program is "compiled" the internal binary representation is no longer "Lisp", it is machine-code. So I think that is besides the point. What matters is the viewpoint of the programmer, what kind of "language" they read and write. From a Lisp-programmer's point of view they write both their data and their functions as lists. For programmers of a homoiconic programming language the programs have the same general structure as data. What better name for such property than "homoiconity"?
  - lispm 7y ago
    The compiled function is a particular end product. But there are stages between source code as text and a compiled function, where the source code as data plays a role: interning of data via the reader, macro expansion, etc... In an implementation with a Lisp interpreter its obvious: the executing code is still the source code as data format. > From a Lisp-programmer's point of view they write both their data and their functions as lists. For programmers of a homoiconic programming language the programs have the same general structure as data. Right, that would be one aspect. Another one is that that source code as data property is actually used in the toolchain. For example PPRINT (pretty print) will create an external representation of a program as text, from the source code in data form. EVAL will take the internal representation and will execute it somehow. The macro expander gets the internal representation and does transformation of those. > What better name for such property than "homoiconity"? Don't know, but 'homoiconic' makes no sense to me. 'iconicity' is a complex concept (or several related ones) and its not clear to me what the obvious meaning of homo-iconicity would be... One can define a meaning for homo-iconicity, though. But I haven't seen a clear and or formal one yet.
    - galaxyLogic 7y ago
      I can manipulate my Lisp-program as a set of nested lists, which is the same structure as I see in my source-code-editor. What I see in the editor is the same structure of nested lists as when I program and execute my macro-definition. My source-code has a 1-to-1 correspondence to the data-structure which is the internal representation of my program (when I execute the macro). The internal (what I manipulate in my code) and external (what I manipulate in my text-editor) representations have the same structure. They are not the "same". But they have the same structure. That is a pretty fantastic property for the language since it makes it simple, I don't need to do a mental translation from the source-code to the structure I can manipulate in my program. Now it seems to me that someone somewhere came up with the name 'homoiconity' for this property. I think that is a much better name than anything else I can think of. 'homo' refers to the self/man/human in Latin and icon refers to “likeness, image, portrait”. So source-code of a Lisp-program is a "picture of the program itself, a picture of itself". Very homo-iconic. > One can define a meaning for homoiconicity, though. It's not like we have words for which we must "define a meaning". It is that we have important concepts which deserve to have a word denoting them. We don't need to "define" a meaning for the word 'homoiconic', we need a word for the generally interesting property of languages like Lisp discussed above. Ah but we already have a word for that: "Homoiconic".

kazinator 7y ago

> Lisp clearly has this property. It is clearly homo-iconic. Firstly "Lisp" is a language family; which member are you talking about? ANSI Common Lisp only hints at a form of homoiconicity, but leaves all of it implementation-defined. Namely, the function ed: http://clhs.lisp.se/Body/f_ed.htm http://clhs.lisp.se/Body/f_ed.htm A Lisp implementation which compiles everything and throws away the source will not support function editing with ed. Compiled functions are not similar to the source; they cannot be edited as source and recompiled. I haven't heard of anyone organizing their Lisp workflow around an ed function, which would then count as relying on homoiconicity. Bash is homoiconic: the set command with no arguments dumps out all function definitions, which are reformatted as text from a tokenized form. There isn't a nice feature to edit a function though, other than copying and pasting out of the output of set, or else recalling the original definition in the history. Speaking of which, interactive environments, including command lines with history recall, provide a form of homoiconicity. The command histories or integrated edit buffers hold functions in their original form, allowing them to be edited and redefined. (But those stored forms are outside of the language; they are not the function definitions themselves. It's not the language per se being homoiconic.) When people say "Lisp is homoiconic", they are certainly not talking about the obscure ed function in ANSI CL. Well, that's what they're not talking about. What they are talking about is anyone's guess, but probably they are using the wrong term for the concept of a language being written in terms of a generic tree data structure that expresses all possible syntax tree shapes, and which is manipulable in that language.

galaxyLogic 7y ago
If a Lisp program is "compiled" the internal binary representation is no longer "Lisp", it is machine-code. So I think that is besides the point. What matters is the viewpoint of the programmer, what kind of "language" they read and write. From a Lisp-programmer's point of view they write both their data and their functions as lists. For programmers of a homoiconic programming language the programs have the same general structure as data. What better name for such property than "homoiconity"?
- lispm 7y ago
  The compiled function is a particular end product. But there are stages between source code as text and a compiled function, where the source code as data plays a role: interning of data via the reader, macro expansion, etc... In an implementation with a Lisp interpreter its obvious: the executing code is still the source code as data format. > From a Lisp-programmer's point of view they write both their data and their functions as lists. For programmers of a homoiconic programming language the programs have the same general structure as data. Right, that would be one aspect. Another one is that that source code as data property is actually used in the toolchain. For example PPRINT (pretty print) will create an external representation of a program as text, from the source code in data form. EVAL will take the internal representation and will execute it somehow. The macro expander gets the internal representation and does transformation of those. > What better name for such property than "homoiconity"? Don't know, but 'homoiconic' makes no sense to me. 'iconicity' is a complex concept (or several related ones) and its not clear to me what the obvious meaning of homo-iconicity would be... One can define a meaning for homo-iconicity, though. But I haven't seen a clear and or formal one yet.
  - galaxyLogic 7y ago
    I can manipulate my Lisp-program as a set of nested lists, which is the same structure as I see in my source-code-editor. What I see in the editor is the same structure of nested lists as when I program and execute my macro-definition. My source-code has a 1-to-1 correspondence to the data-structure which is the internal representation of my program (when I execute the macro). The internal (what I manipulate in my code) and external (what I manipulate in my text-editor) representations have the same structure. They are not the "same". But they have the same structure. That is a pretty fantastic property for the language since it makes it simple, I don't need to do a mental translation from the source-code to the structure I can manipulate in my program. Now it seems to me that someone somewhere came up with the name 'homoiconity' for this property. I think that is a much better name than anything else I can think of. 'homo' refers to the self/man/human in Latin and icon refers to “likeness, image, portrait”. So source-code of a Lisp-program is a "picture of the program itself, a picture of itself". Very homo-iconic. > One can define a meaning for homoiconicity, though. It's not like we have words for which we must "define a meaning". It is that we have important concepts which deserve to have a word denoting them. We don't need to "define" a meaning for the word 'homoiconic', we need a word for the generally interesting property of languages like Lisp discussed above. Ah but we already have a word for that: "Homoiconic".