“I believe the author is misreading this definition.” Agreed. Author has tied self in knots from overthinking it. Homoiconicity has nothing to do with external

“I believe the author is misreading this definition.” Agreed. Author has tied self in knots from overthinking it. Homoiconicity has nothing to do with external [text] representation and parsing (deserialization). Homoiconicity in a programming language means that every complete program is a composition of the language’s core datatypes, and nothing more. OP’s suggestion that homoiconicity could be a sliding scale is nonsense. A language is either homoiconic, or it isn’t. Here’s a simple test: many languages have first-class functions/procedures/handlers, but most of them do not first-class commands. Any language which has commands which are not values cannot be homoiconic. A Lisp program is composed entirely of Lisp’s atomic types (`number`, `string`, `symbol`) and fundamental collection type (`list`). Lisp, being an exercise in extreme parsimony, does not define a discrete `command` type but instead overloads its `list` datatype to operate as either a command or a list according to context. Thus commands in Lisp can be created, manipulated, passed around, and evaluated at any time, using the exact same toolset as is used to create, manipulate, pass around, and evaluate Lisp lists. Or my own kiwi language defines six core datatypes—`null`, `text`, `name`, `list`, `command`, `tag`—from which all kiwi programs are composed. Command values can be created, stored, passed around, and evaluated just the same as any other value. e.g. Here’s a slightly contrived example which stores a list of arbitrary commands, then later retrieves and passes them as the argument to another command (`vowels`), which passes them on to a primitive procedure (`apply to pattern`) where they’re finally applied to the input data: R> store value (x, (case (upper), bold)) R> R> define rule (vowels (format), apply to pattern (“[aeiou]”, {$format})) R> R> ^^ hello world R> vowels ({$x}) # “hEllO wOrld” Compare and contrast to a C-family language such as Python. While some language structures (integer, string, list, function literals) do have native datatype representations, other structures (operators, statements, function calls) do not. While it’s still possible to manipulate Python program structures using Python’s `ast` APIs, or pass around sequences of hardcoded commands by wrapping them in lambdas, everything is second-class, with all the additional indirection and complexity that entails. Still, look at how popular and useful Python is, despite such expressive limitations, while Lisp, for all its meta-circular power, is stuck firmly on the fringes. . So how could homoiconicity be useful? Well, consider this thread: <https://news.ycombinator.com/item?id=20662232> https://news.ycombinator.com/item?id=20662232>, discussing the current challenges of building programs by voice dictation. Voice-coding languages such as C and Python require lots of special “control words” to input complex syntactic structures—operators, statements, punctuation, and so on. A language where all code structures are primitive data types only needs words to describe those data structures, and since fundamental data structures like quoted strings and lists are inherently self-describing, tedious mechanical details like precise punctuation can probably be inferred automatically from a combination context-aware autocomplete and voice cadence (e.g. meaningful pauses, end-of-sentence pitch changes). In the land of blind-dumb algorithms, Compositionality may yet be King.