Talk:Meta-circular evaluator

message: The core of Rubinius is written in C, and most all other parts are written in Ruby. Does writing the core parts in another language not disqualify Rubinius as a meta-circular language? Is the fact that the other parts of the interpreter are written in Ruby what makes Rubinius meta-circular? -- lennarth 07:00, 28 September 2007 (UTC)
replies: text: According to Evan Phoenix, it is not. -- FF-Wonko T•C 19:35, 15 December 2008 (UTC)

text: Update: According to Evan, it is "meta-circular"ish. All (including the compiler) but the VM is written in Ruby. -- FF-Wonko T•C 17:51, 16 December 2008 (UTC)
replies: text:  The current definition of the article does not merely require the interpreted and implementation languages to be the same, as done by SICP, but it is more specific, and I doubt Rubinius can agree with this more restrictive definition. --Blaisorblade (talk) 09:46, 28 October 2010 (UTC)
thread_title: Untitled

message: PyPy reasons about Python code by first parsing it.  Homoiconicity helps avoid the need to parse the language, thus making it easier to build the meta-interpreter.
--87.69.224.131 (talk) 20:33, 22 March 2010 (UTC)
thread_title:  Homoiconicity is a Relative Matter 

message: The eval function (also available in Python, ECMAScript and others) is merely a re-invocation of the interpreter.  I don't think that counts as meta-circular.  This is not an implementation of Perl in Perl, this is merely calling a C function which happens to implement Perl.
--87.69.224.131 (talk) 20:33, 22 March 2010 (UTC)
thread_title:  Does Perl count? 

message: The content of this article is apparently based on a misunderstanding of the term meta-circular evaluator.  The term meta-circular was coined in
:John C. Reynolds, "Definitional Interpreters for Higher-Order Programming Languages, Proceedings of the ACM Annual Conference, 1972, (vol. 1) pp. 717–740.  Reprinted in Higher-Order and Symbolic Computation 11 no. 4 (December 1998), pp. 363–397.
The technique Reynolds describes is the definition of the semantics of a programming language L1 by providing an interpreter for programs of L1 written in a programming language L2.  Although sometimes L2 is a subset of L1, it isn't usual for L2 to be identical to L1, and indeed if they were identical then the interpreter would constitute a circular definition, rather than merely meta-circular.  At the time Reynolds was writing there was a serious shortage of good techniques for defining the semantics of programming languages, and he noted, from that point of view, that although the technique might not be circular as a definition of any specific language, at the meta-level (so to speak) it can't tell you what the entire class of programming languages is because you have to already know some one programming language.  So it's a "meta-circular" definition.
I don't know, for sure, when or how people started confusing the term with the orthogonal concept of self-interpretation, although my guess (pure speculation) is that it post-dates Structure and Interpretation of Computer Programs, where the term meta-circular is used but not clearly defined.  This despite the fact that the meta-circular technique described in SICP includes modifying the meta-circular evaluator so that it interprets languages pointedly different from the language in which the evaluator itself is written. --Pi zero (talk) 22:56, 30 March 2010 (UTC)
replies: text: According to your summary, Reynolds just defined meta-circular, not meta-circular interpreters. There are various definitions of meta-circular interpreter - I did not read the paper you mention (even though it is on my reading list), but the definition used in the article agrees, for instance, with Programming Languages: Application and Interpretation. According to this definition, SICP is _wrong_, as I just noted in the article. My current working hypothesis is that the concept got more and more refined over time.--Blaisorblade (talk) 09:43, 28 October 2010 (UTC)
thread_title:  Misuse of the term meta-circular 

message: SICP confuses these two categories of interpreters, and the same confusion shows up in the article. PyPy, Rubinius, Jikes are probably _not_ meta-circular interpreters. For instance, Jikes implements a set of Garbage collectors, rather than relying on the GC of the host environment. Same for PyPy - its developers explicitly state they are not doing metacircular evaluation. See for instance PyPy’s Approach to Virtual Machine Construction. I wrote something but I wanted to discuss the confusion here - the very idea that SICP is wrong suggests more investigation (especially since I'm not expert and I can't really compare the two books which I'm citing, even if I'm a beginning PhD student in the area). --Blaisorblade (talk) 09:43, 28 October 2010 (UTC)
thread_title:  Metacircular vs self interpreters 

message: According to the paper quoted below meta-interpreters are far more important than currently indicated in the article
[I]t is worth noting that a Universal Turing Machine can be considered as simply a meta-interpreter incorporated within hardware. In this sense, meta-interpretation is one of, if not the most fundamental concept in Computer Science.(, also to appear in the Machine Learning Journal in 2015)
pgr94 (talk) 16:12, 25 November 2014 (UTC)
thread_title:  Significance understated? 

message: Is it true that the apply and eval functions are examples of meta-circular evaluators, as stated here? Jarble (talk) 20:01, 4 November 2021 (UTC)
thread_title:  ''apply'' and ''eval''