Like most people, I'm going to keep using the word "homoiconic" because it is a useful term.<p>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.<p>Everything in software is, at some level, an abstraction. And that's okay.<p>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.<p>I agree that homoiconicity is not strictly boolean, but that doesn't make it a useless concept.
How about "defining" homoiconic to mean that it's easy to manipulate programs? More specifically, say a programming language is homoiconic if (1) the standard library for the language includes a parser, and (2) the parser returns data structures that are easily manipulated by functions in the standard library.<p>Point (2) can be achieved by having the parser return generic data structures such as lists, arrays and hashtables for which the standard library will probably have lots of convenient functions (this what Lisps do); or by having a dedicated AST data type, but including a bunch of AST manipulation functions in the standard library (like Template Haskell).<p>Of course, this isn't a very precise definition because it relies on the undefined terms "parse" and "easily manipulated". Does read_file_to_string() count as a (trivial) parser that produces strings, which can be easily manipulated by standard string functions? The idea is this doesn't count, but I'll leave the problem of defining what counts as a parser to other philosophers of programming languages. :)
> "In a homoiconic language, the primary representation of programs is also a data structure in a primitive type of the language itself."<p>I believe the author is misreading this definition.<p>> "First, consider that most languages have a primitive datatype for strings of text"<p>The defintion says "data structure", not "datatype". A string is a datatype, not a datastructure.<p>> "Second, for most languages, it is possible to write a parser in that language itself, that stores the resulting abstract syntax tree in a primitive type in the language."<p>This is completely besides the point as the definition references the "primary representation", not a represenation that can be built using a parser.
I haven't found the term particularly useful either. What I do like to say is that in Lisp, <i>the AST is a public interface</i>. That is, the AST is defined by a specification and is not going to change, so that you can write code that manipulates it and know that the next compiler version won't break your code — indeed, it's portable across implementations. Also, the AST's structure is relatively simple to explain (though there are some "gotchas" you have to watch out for when manipulating it, like inadvertent variable capture), and macros provide a convenient interface for receiving an AST from the compiler or interpreter and supplying back a transformed AST.<p>Other languages could provide similar facilities, and indeed a few have done so. But the more complex the syntax of the language, the more difficult it is to do that in a usable way.
I agree with the conclusion, that what we call homoiconicity is a scalar, not a boolean. And I agree both in this case and in general that people should talk about languages more directly (“the syntax is easy to parse”, “the semantics of the language are completely defined on the single page of a book”) rather than label them as homoiconic or not.<p>If you'd like good argument for writing in languages that call themselves homoiconic, you can see Bawden's Quasiquotation in Lisp. Its section 2.1 compares writing a program that generates programs in C, versus Lisp, first without quasiquotation, then with.<p><a href="https://3e8.org/pub/scheme/doc/Quasiquotation%20in%20Lisp%20(Bawden).pdf" rel="nofollow">https://3e8.org/pub/scheme/doc/Quasiquotation%20in%20Lisp%20...</a>
"... the original definition: languages which have the same external and internal representations are homoiconic."<p>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."<p>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.<p>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.<p>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?<p>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.
An excellent talk by Sturart Sierra that covers much of the same ground "Homoiconicity: It Is What It Is"
<a href="https://www.youtube.com/watch?v=o7zyGMcav3c" rel="nofollow">https://www.youtube.com/watch?v=o7zyGMcav3c</a><p>spoiler: his talk also does not finish with a definition of homoiconic either
To me this article feels like someone working really hard to find an objection to something (may or may not be true, but it feels that way to me).<p>The first line of the article's conclusion is "Homoiconicity is a term surrounded by much confusion." I simply do not agree with this assertion.<p>I was introduced to the term many years ago, and I have have read it in numerous contexts, and the meaning has been quite clear in every context I can recall.<p>I also will keep using it the way I am now, since I see absolutely no reason to stop.
My only problem is that the term is a feature not a benefit. The two most powerful ideas in lisp are the lack of statements (everything is an expression, even atoms) and the macrology (which pretty much requires expression-only, and of course requires the Mooers/Deutsch coinage of...homoiconicity).<p>Eval is great but unavoidably requires special forms. That's just life: you can't be circular; at best you can be metacircular. It's like the second law of thermodynamics.
This is a great article. It takes a pedantic point about an answer that "everybody knows", and manages to make a compelling case that the way we use this vocabulary is suboptimal.<p>Great find!
I'm not a big fan of 'homoiconic' either. I'm more in the 'source code as data' camp.<p>> The first objection concerns the external representation. In the above we simply stated that the external representation is an s-expression. In most practical programming environments, however, the actual representation of program sources is as text files which contain strings of characters. It is only after parsing this text that the representation is really an s-expression. In other words: in practical environments the external representation is not an s-expression, but text.<p>The point is that Lisp s-expressions are an external representation of data and that Lisp programs are represented as s-expressions. Various programmatic interfaces see this source code as data: for example the function EVAL or the macro expander.<p>> The second objection concerns the internal representation. Practical implementations of Lisp interpreters do generally not operate actually directly on s-expressions internally for performance reasons.<p>Actually they do. The definition of 'Lisp interpreter' is that it operates on source code as data (lists, symbols, ...). Lisp has other ways to execute: as compiled byte code, as compiled native code, etc. -> but that's not a Lisp interpreter.
I always had the impression homoiconicity could be used to do interesting machine learning applications, becauee the programm could easily modify itself. Did this happen?
<a href="http://taeric.github.io/CodeAsData.html" rel="nofollow">http://taeric.github.io/CodeAsData.html</a> is where I took my stab. Lisp is the main language I know where you can write a function, and write code that can both symbolically run a derivative, and let you use that derivative just like any other function. Without having to dive into a bunch of AST specific structures to do it.<p>It really is a shame that people think the eval of javascript and python is equivalent to the eval of lisp. It is crazy just how different they are, once you see it.
Kind of echoes a reddit comment I wrote two years ago:<p><a href="https://www.reddit.com/r/lisp/comments/5h2kdc/homoiconicity/dax1ude/?st=jz91ye0l&sh=92838870" rel="nofollow">https://www.reddit.com/r/lisp/comments/5h2kdc/homoiconicity/...</a>
What about using the word "homoiconic" when we mean its meaning: "homogenous icons" other said, a regular and equivalent representation of all its tokens. The article sort of tries to validate its point from a historical approach, but kind of ignores the meaning of the word by its compounds. Will continue using it.