# Is JavaScript a homoiconic language?

I can't help but notice the uncanny resemblence JavaScript has to LISP. JSON (JavaScript Object Notation), for instance, is a data structure that can be reconstituted into an object by subjecting it to an eval() function. Likewise, LISP data can also be executed as code.

This leads to my question: Is JavaScript Homoiconic or at least partially so? If not, why?

• What is your definition of "homoiconic"? – Derek Elkins left SE Sep 15 '19 at 3:02
• You know it's a good question. It's hard to define. I guess it code and data structures are interchangeable. – user148298 Sep 15 '19 at 19:54

Given your definition, the answer is "no". JavaScript syntax is not a subset of JavaScript's literal syntax. The fact that a value a literal represents can be produced by evaluating the literal is what makes a literal a literal and is true in any language. The only real difference is JavaScript has a richer literal syntax than many common programming languages, though this is certainly not a rare thing.

The answer is "no" for pretty much any reasonable definition that doesn't make practically every language "homoiconic".

My impression is there is not a clear consensus of what "homoiconic" means within the Lisp community. Part of that is it seems many Lispers are confused1 about "homoiconicity"2. I recommend this article which goes over the variety of possible definitions of "homoiconic" and the issues with each. As the title of that article is "Don't Say 'Homoiconic'", this suggests worrying about whether a language is "homoiconic" is not a great idea and you should be more specific about what it is you are care about.

If we use the definition referenced in the article, namely "having the internal and external representations be the same", then this definitely doesn't apply to JavaScript (to the extent that it even makes sense). It arguably doesn't apply to Lisp either, but there are various ways where Lisp gets closer to this. One small indicator is that Lisp's eval takes in Lisp lists while JavaScript's takes in strings. This separation holds for the actual Lisp implementation as well as parsing is viewed as conceptually outside of the implementation and so the implementation conceptually works upon Lisp lists. This has non-trivial consequences like being able to provide circular syntax and an abstract syntax graph in general.

1 Frankly, understandably so as the explanations tend to be vague. There is also, at this point, a lot of misinformation.2

2 There are many definitions floating around that whatever "homoiconic" should mean if anything doesn't mean these things such as "supports higher-order functions".

• Generally, I'm not really sure what "uncanny resemblance" to Lisp you see in JavaScript. JavaScript was explicitly inspired by Scheme, but beyond being dynamically typed, having higher-order functions, and having a moderately rich literal syntax, it doesn't share much with Scheme. Those properties, however, are far from exclusive to Scheme and are shared by Python, Perl, and Ruby. Unless you consider practically every dynamically typed language to have an "uncanny resemblance" to Lisp, it's not very clear why you'd think that of JavaScript. – Derek Elkins left SE Sep 15 '19 at 21:44
• I stumbled on this article where the author claims JavaScript is homoconic. erichosick.com/design/design-javascript-and-homoiconicity – user148298 Sep 15 '19 at 22:34
• I'm not sure if the author of that article is saying that JavaScript is "homoiconic", though that may well be what they intend. As I mentioned, there is tons of confusion and misinformation on this topic, and this is a good example of it. What the author describes can be done in basically any Turing-complete language. The author of that article simply wrote an interpreter for a very basic language but seemingly doesn't realize that. – Derek Elkins left SE Sep 16 '19 at 0:56