Jump to content

Talk:Meta-circular evaluator

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Is Rubinius really meta-circular?

[edit]

Untitled

[edit]

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)[reply]

According to Evan Phoenix, it is not. -- FF-Wonko TC 19:35, 15 December 2008 (UTC)[reply]
Update: According to Evan, it is "meta-circular"ish. All (including the compiler) but the VM is written in Ruby. -- FF-Wonko TC 17:51, 16 December 2008 (UTC)[reply]
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)[reply]

Is homoiconicity really a requirement?

[edit]

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

[edit]

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)[reply]

Does Perl count?

[edit]

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)[reply]

Misuse of the term meta-circular

[edit]

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)[reply]

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)[reply]

Metacircular vs self interpreters

[edit]

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)[reply]

Significance understated?

[edit]

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)[reply]

apply and eval

[edit]

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)[reply]