Talk:Meta-circular evaluator

Untitled

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)

According to Evan Phoenix, it is not. -- FF-Wonko ^T•C 19:35, 15 December 2008 (UTC)

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)

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)

Is homoiconicity really a requirement?

Python, for instance, is not considered homoiconic, yet is listed here as having a third party metacircular interpreter. Unless we consider the file to be the datastructure in which code is stored (thus making it homoiconic) I think we should remove this claim. It is not supported by the citation, either.

Homoiconicity is a Relative Matter

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)

Does Perl count?

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)

Misuse of the term meta-circular

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)

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)

Metacircular vs self interpreters

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)

Significance understated?

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.([1], also to appear in the Machine Learning Journal in 2015)

pgr94 (talk) 16:12, 25 November 2014 (UTC)

apply and eval

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)