Talk:Homoiconicity
This is the talk page for discussing improvements to the Homoiconicity article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||
|
How to pronounce Homoiconicity?
[edit]How do you properly pronounce the word? How do you explain the pronunciation in proper phonetic markup?
Smalltalk and other languages
[edit]I don't think smalltalk is homoiconic: http://c2.com/cgi/wiki?HomoiconicFaq
It is countered at the same place. (the only argument seems to be on the degree of homoiconicity.) Blufox (talk) 19:35, 31 December 2007 (UTC)
Smalltalk's ability to make library features appear as if they were built-in language features makes many things very easy, including handling code. That does not make Smalltalk homoiconic, not even weakly, though. Yes, Smalltalk byte code can be manipulated at runtime, but so can Java byte code. I believe no one would like to go as far as stating that Java is homoiconic. There should be a distinction between a language with reflective abilities (Smalltalk) and a language that is homoiconic (Lisp). ClassA42 (talk) 03:48, 2 April 2009 (UTC)
Can the languages that feature integrated macro facility be considered homoiconic? -- i.e code is manipulated as data? (It seems to fit the arguments given in the page refered in c2wiki). If that is the case quite a few other languages will fit the description. e.g. logo Blufox (talk) 04:37, 9 January 2008 (UTC)
History of homoiconicity in LISP
[edit]It might be interesting to add how the homoiconicity of LISP is entirely accidental. McCarthy and company thought in M-expressions and used S-expressions as a quick hack to get going, one that was always going to be replaced someday. Eventually it was realized that they'd stumbled upon a very powerful thing. Hga (talk) 22:05, 5 August 2009 (UTC)
That's utter bull. M-expressions were intended as a publication language, but fell by the wayside when LISP became primarily a programming language rather than a tool for communicating about algorithms. The whole reason for S-expressions was their homoiconicity, allowing the LISP reader to be expressed in LISP. -- 96.247.231.243 (talk) 04:36, 10 May 2014 (UTC)
Why not Forth?
[edit]Doesn't Forth also have this property? --96.233.96.41 (talk) 11:11, 7 August 2011 (UTC)
No, Forth source code is space separated text tokens, while Forth executable code is threaded binary pointers. Not the same thing. But PostScript is homoiconic. Xardox (talk) 20:48, 1 September 2019 (UTC)
By that reasoning, Lisp wouldn't be homoiconic either. Lisp is text tokens in nested parentheses, while Lisp executable code is a binary tree of symbols. Ryan Avella (talk) 16:47, 5 April 2021 (UTC)
Missing date
[edit]"History" would imply dates. Don't make people scroll to the references to find out when the papers were written.
24.128.9.100 (talk) 20:44, 26 April 2014 (UTC)
Don't you have a mouse? Put it over the reference number and the reference appears. -- 96.247.231.243 (talk) 04:39, 10 May 2014 (UTC)
Non-S-expression homoiconic languages. Versions of homoiconicity or levels? Julia homoiconic?
[edit]Hi, I think I understand this concept and the LEAD fits it for LISP. For a more "normal" language like Julia (that is listed here, and its page links here without using the word), the LEAD doesn't seems to fit. While all languages I know (maybe except Prolog?) can be expressed as an AST, doesn't homoiconic meant that you can access that representations (from the REPL, or at any time with eval?)? Does the language itself have to be a AST? Julia seems just to allow for both infix and prefix notation. And does this feature allow for things like Racket_features#Language_Extensions, even a Prolog-like language? All language that have this concept equivalent in that sense? [Julia allows not just access access to the AST, but also the compiled machine code from the JIT. Is that unusual or in a way related to this?] comp.arch (talk) 14:14, 16 June 2014 (UTC)
See also M-expression: "While it is not uncommon for Lisp programmers to devise an alternate form for the language (of which MLISP is one example), some of which use M-expressions, such dialects generally lack the homoiconicity of S-expressions[dubious – discuss], which is considered an important part of the expressiveness of the language."
I wouldn't have thought of Prolog as homoiconic and can't really see that you could do similar stuff in it as you can in Racket (see above). I wander however if you can in Julia, or all homoiconic languages, and if it makes all of them as expressive/powerful. Maybe not and all these are needed (and would Julia have them)[1]? Se also: [2][3][4] comp.arch (talk) 13:23, 29 July 2014 (UTC)
PostScript is homoiconic
[edit]PostScript code is represented as PostScript data (executable arrays, names, and literals), so PostScript is homoiconic.
To illustrate this, here is a PostScript Quine from Stan Switzer at https://donhopkins.com/home/archive/NeWS/news-tape/fun/quine/quine
{{[ exch /dup load /exec load ] cvx} dup exec}
Here are some articles that mention its homoiconicity:
"Getting started with postscript" at https://postscript.programmingpedia.net/ and also "Learning PostScript" at https://riptutorial.com/Download/postscript.pdf : "Like LISP, PostScript is homoiconic and code and data share the same representation. Procedures can take procedures as data and yield procedures as results, lending itself to techniques from concatenative-programming as well."
I've written about PostScript code and data:
"The Shape of PSIER Space" at https://medium.com/@donhopkins/the-shape-of-psiber-space-october-1989-19e2dfa4d91e "Interacting with the Interpreter: In PostScript, as in Lisp, instructions and data are made out of the same stuff. One of the many interesting implications is that tools for manipulating data structures can be used on programs as well."
https://news.ycombinator.com/item?id=18317280 "The beauty of your functional approach is that you're using PostScript code as PostScript data, thanks to the fact that PostScript is fully homoiconic, just like Lisp! So it's excellent for defining and processing domain specific languages, and it's effectively like a stack based, point free or "tacic," dynamically bound, object oriented Lisp!"
It might be nice to have a section about PostScript, perhaps using the PostScript quine as an example, explaining how it works, and how it's similar in structure to quines in other homoiconic languages like Lisp (and even non-homoiconic languages like BASIC). I would be happy to help write it. — Preceding unsigned comment added by Xardox (talk • contribs) 20:18, 1 September 2019 (UTC)
Mistake in the Origin Story of the term.
[edit]The original source of the term is the TRAC paper itself, not the McIlroy paper. In the TRAC paper, the footnote on "homoiconic", footnote 4, says "Following suggestion of McCullough, W. S., based on terminology due to Peirce, C.S." footnote 5, which cited McIlroy (the letter "s" appears in the Wikipedia article, presumably mis-reading "5"), observes merely that TRAC was inspired by McIlroy's work on macro assembler languages.
W.S. McCullough likely refers to the cybernetician Warren Sturgess McCullough, of whom there is a Wikipedia page. C.S. Peirce surely refers to the logician Charles Saunders Peirce, who also has a Wikipedia page. --Ron.garcia (talk) 01:29, 20 February 2020 (UTC)
- Hi Ron! I came to your comment because I just came to the same conclusions. I chased down the TRAC paper, and McIlroy's paper. Ilroy had nothing to do with "homoiconic" whatsoever. I will repair the article. KazKylheku (talk) 06:17, 9 July 2023 (UTC)
- I think there's probably more of the story in Calvin N. Mooers's papers, like maybe homoiconic is also in the 1964 research report cited in the ACM Trac paper, with the author names written out in full so we don't have to guess who he's citing, but I'm not really ready to fly out and check. If you're reading this, you live near Minneapolis, and you have some free time... why not spend some time researching and improving Wikipedia? Mathnerd314159 (talk) 19:05, 9 July 2023 (UTC)
On the disputed nature of Julia’s homoiconicity
[edit]So I know @Rikivillalba added a “citation needed” tag when Julia was mentioned as homoiconic. They said that Julia’s homoiconicity status was controversial, citing a Stack Overflow discussion in which one of the Julia creators, Stefan Karpinski, said,
“This term is sufficiently controversial that we no longer say that Julia is homoiconic – so you can decide for yourself whether it qualifies.”
Clearly there is a controversy worth mentioning here, so thanks @Rikivillalba for bringing that up. I plan to replace the “citation needed” tag with a direct mention of the controversy in the article. I will also cite the Stack Overflow discussion as a primary source. Stack Overflow would not be a reputable secondary source, but since the Julia creators are the ones writing the answer, I think this qualifies as primary.
If there are any objections, please feel free to tag me. Wham Bam Rock II (talk) 04:56, 1 August 2022 (UTC)
Definition
[edit]This term seems to lack an agreed upon definition?
see https://www.expressionsofchange.org/dont-say-homoiconic/ Spdegabrielle (talk) 12:35, 20 November 2023 (UTC)
- Well, yes and no. There is the TRAC definition, as in that blog post and in this article's history section, which seems well-accepted. Nobody is contesting that TRAC is homoiconic - they coined the term. The issue is rather one of scope - the term should be broader than TRAC, but the line between homoiconic and non-homoiconic is not clear. For example there has been some controversy as to whether Julia is actually homoiconic. There don't seem to be multiple definitions of the term in play, rather it is that the TRAC definition is more poetic than practical so people have difficulty applying it and the result is that the only homoiconic language anyone recognizes is Lisp and Lisp has become the de-facto definition of homoiconicity. Sigh.
- I found a source which supports the initial definition presented in this article's lead since 2006. Since the phrasing in the paper is identical, maybe it is citogenesis, but I think that is probably the best it'll get. Mathnerd314159 (talk) 23:40, 20 November 2023 (UTC)