4 ms·

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

by 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".
- lispm 7y ago
  > structure I don't see the connection of this kind of structure, with 'iconicity'. Iconicity is usually more concerned with the form of a symbolic shape and the connection to its meaning. Structural aspects can play a role, but they are still connected to some meaning (which connects it to the human understanding). Source code in a text editor is not a 'picture' or 'shape' or 'icon'.
  - galaxyLogic 7y ago
    Source-code in a text-editor has a shape. Lisp source-code in a text-editor has a structure expressed with parentheses. 'icon' refers to “likeness, image, portrait”. The structure of Lisp source-code is the same as the structure of the internal representation of the same program produced from that source-code which your Lisp program can see and manipulate. There is "likeness", meaning iconicity, between the two representations, because the two structures are "alike".
    - kazinator 7y ago
      Even if that fits under Doug McIlroy's definition of "homoiconic" (which sits in a paywalled 1960 paper), the C preprocessor probably also meets the definition, as do function definitions in Bash. "Homoiconic" is not a word that denotes something special about Lisp that separates it from low-brow hacks. The authors of TRAC were familiar with Ilroy's paper and its neologism, and cheerfully applied it term to their purely text-based system. Either they didn't understand the word, or else it really does cover that kind of thing.
    - lispm 7y ago
      > Source-code in a text-editor has a shape. not an iconic shape > 'icon' refers to “likeness, image, portrait”. source code is none of that. it's text.
      - galaxyLogic 7y ago
        Source-code is not only text. It has structure which must follow specific syntactic rules. It is not free-form text like what we are writing here. It has structure which is the same thing as saying it has 'shape'. And that shape "forms" an image, is iconic, for the internal structure of the program which you see when you manipulate it within your Lisp-program. An image is not the same thing as the thing being imaged. Ceci'nest pa une pipe. But you can see the structure of the thing being represented by looking at the image, by the "icon", why, because the structure of the image is (to a large degree) same as the structure of the thing being imaged. Similarly the syntactic structure of Lisp source-code let's us see the structure of the program that is generated by that source-code. It is iconic. It is iconic to the thing it represents, the program, which in a sense is the same thing, just a different, but structurally isomorphic representation of the program itself. It is homoiconic.

by lispm 7y ago

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".

lispm 7y ago
> structure I don't see the connection of this kind of structure, with 'iconicity'. Iconicity is usually more concerned with the form of a symbolic shape and the connection to its meaning. Structural aspects can play a role, but they are still connected to some meaning (which connects it to the human understanding). Source code in a text editor is not a 'picture' or 'shape' or 'icon'.
- galaxyLogic 7y ago
  Source-code in a text-editor has a shape. Lisp source-code in a text-editor has a structure expressed with parentheses. 'icon' refers to “likeness, image, portrait”. The structure of Lisp source-code is the same as the structure of the internal representation of the same program produced from that source-code which your Lisp program can see and manipulate. There is "likeness", meaning iconicity, between the two representations, because the two structures are "alike".
  - kazinator 7y ago
    Even if that fits under Doug McIlroy's definition of "homoiconic" (which sits in a paywalled 1960 paper), the C preprocessor probably also meets the definition, as do function definitions in Bash. "Homoiconic" is not a word that denotes something special about Lisp that separates it from low-brow hacks. The authors of TRAC were familiar with Ilroy's paper and its neologism, and cheerfully applied it term to their purely text-based system. Either they didn't understand the word, or else it really does cover that kind of thing.
  - lispm 7y ago
    > Source-code in a text-editor has a shape. not an iconic shape > 'icon' refers to “likeness, image, portrait”. source code is none of that. it's text.
    - galaxyLogic 7y ago
      Source-code is not only text. It has structure which must follow specific syntactic rules. It is not free-form text like what we are writing here. It has structure which is the same thing as saying it has 'shape'. And that shape "forms" an image, is iconic, for the internal structure of the program which you see when you manipulate it within your Lisp-program. An image is not the same thing as the thing being imaged. Ceci'nest pa une pipe. But you can see the structure of the thing being represented by looking at the image, by the "icon", why, because the structure of the image is (to a large degree) same as the structure of the thing being imaged. Similarly the syntactic structure of Lisp source-code let's us see the structure of the program that is generated by that source-code. It is iconic. It is iconic to the thing it represents, the program, which in a sense is the same thing, just a different, but structurally isomorphic representation of the program itself. It is homoiconic.