Talk:Interpreter (computing)

This page does not explain what in interpreter IS

This page does not explain what in interpreter IS but rather discusses all the technical minutia which is uninteresting to an average reader like me. I just want to know what an interpreted language is. Could someone please someone make this page simpler? Truetyper 03:40, 18 May 2007 (UTC)

• Done. (I had the same problem with it.) -- algocu 15:03, 23 May 2007 (UTC)

should this be at Interpreter (computing), to match with the many other computer-related entries? Catherine, your friendly neighborhood not-quite-that-computer-literate disambiguator

---

I think we should remove that code. It's too long and technical for the average reader, and it doesn't really convey anything. Plus it's in a nasty language. CGS 11:40, 24 Aug 2003 (UTC).

A lot of the mathematical pages contain definitions which are too long and technical for the average readers and don't really convey anything to them either, but that's not a reason for removing them, so it shouldn't be a reason for removing this code. Remember that "average" covers a range and therefore some average readers will be able to understand the code just as some average readers will be able to understand the mathematical pages.

In any case 93 lines (including blank ones) isn't particularly long for a minimal interpreter. And in my opinion, including an example of an interpreter conveys the idea that interpreters can be short, simple programs like any other and can be written in any language, even one as "nasty" as BASIC. The "nasty language" thing is a matter of opinion, of course. All programming languages are nasty to the average reader, after all. This particular nasty language is at least a widespread one.

If you want to replace the example code by a shorter, more comprehensible equivalent written in your own favourite nasty language, feel free but don't just delete the existing code without producing some replacement. When it comes to technical articles, examples are goood for the average reader. -- Derek Ross 16:42, 24 Aug 2003 (UTC)

Second vote for removal/replacement. The source code for an interpreter is not an interpreter, and while BASIC is (err) basic, it is still technical, I wouldn't consider it readable by your "average" joe.

I would suggest a better example would be illustrate what an interpreter does rather than how an interpreter is implemented. For this it is ok to use BASIC as a sample interpreter, but more along the lines of (excuse my BASIC - very rusty 8-)

Source file to be interpreted	Output from BASIC interpreter
FOR i = 1 TO 3 PRINT i; " is a number" NEXT i	1 is a number 2 is a number 3 is a number

If necessary, this example (or similar) could be beefed up by describing the action of the interpreter as it processes the source file, maybe in contrast to a compiled (object) version of the same code.

I would also remove the corresponding section from Literate programming. The example given is not literate programming. Maybe a simple example from a 20-line Java class? -- AndrewKepert 04:32, 25 Aug 2003 (UTC)

The example is nasty, weird, and has little to do with Literate programming, do as discussed. -- Anon reader

Well don't just whine about it. It's supposed to be a minimal piece of code, not a thing of beauty. If you don't like it, fix it. This is a wiki after all. -- Derek Ross | Talk

Lisp is an "interpreter". The basic definition is quite elegant, written in Lisp, and about half a page in length. How about using it? --AJim 05:30, 15 Dec 2004 (UTC)

The main problem with Lisp is that you would also need to supply a lisp-machine of some sort to run the Lisp interpreter on. I have implemented a version of the SECD machine in BASIC which could be used but the combination of QBASIC, SECD machine, SECD Lisp interpreter and Lisp Lisp interpreter is quite complex to load and wouldn't really be any easier to understand than the current interpreter since the "elegant" interpretive top layer relies on a rather "uncouth" compiled substrate. Looking on the bright side of course, it would be more general since it would be able to interpret user defined functions and lambda expressions. -- Derek Ross | Talk 06:01, 2004 Dec 15 (UTC)

In the first paragraph, it states that "the first interpreted high-level language was probably Lisp." It seems like the "probably" can be nailed down. I don't know where this could be researched, however. Having "probably" seems a little mealy-mouthed. Chris van Hasselt (talk) 15:30, 2 January 2013 (UTC)

Why is an interpreter defined as a computer program?

I always thought that the primary example of an interpreter was a computer processor - reading machine language and interpreting it. Machine language is always in the imperative tense - do this, next do that, next... In my mind, an interpreter is something that does what the language says to do, as opposed to a translator, whose purpose is to convert the (imperative) meaning into another form that is, most commonly, easier to interpret. Many "machine languages", in fact, are interpreted by another machine, running "microcode", and so they have a quite formal equality with other interpreted languages. So, I would like to take "computer program" out of the definition. AJim 01:12, 25 Jun 2004 (UTC)

I think that that is a perfectly reasonable view and worth adding to the article. Please do so. However the article does capture the more commonly used meaning of interpreter which is normally applied to computer programs which translate in a particular repetitive way. I think that it would be going too far to remove the discussion of that meaning. Both are important. -- Derek Ross | Talk 02:04, 2004 Jun 25 (UTC)

Also, microcode is out of sight in most architectures except x86, and even then it's only used for particular operations.--Blaisorblade (talk) 03:16, 6 August 2010 (UTC)

JIT

I'm not convinced of JIT being "several decades" old, at least with regard to Smalltalk. "several decades" presumably is at least two. I'm pretty sure that in December of 1984, Smalltalk did not do any JIT. The bytecodes were strictly interpreted in all Smalltalk implementations of that day of which I've heard. I'm not sure if or when JIT was introduced in the Smalltalk world, but it seems unlikely that it would have been deployed before the 1990s (or very late 1980s). --Brouhaha 18:51, 1 Dec 2004 (UTC)

I'm currently doing my thesis at an OO programming language engineering lab at my university, I'll talk to some people and ask about it.--wlievens

Incremental compilation (pretty much the same thing as JIT) was used in Maclisp in the '70s. --FOo (talk) 20:56, 5 October 2008 (UTC)

"Efficient implementation of the Smalltalk-80 system" is a paper published in 1984 which describes JIT compilation and a whole lot of other techniques introduced back then and which form the basis of every modern Virtual Machine (inline caching comes to mind). --Blaisorblade (talk) 03:25, 6 August 2010 (UTC)

The Example

Wouldn't a scaled-down version of the Scheme meta-circular interpreter from SICP be more interesting as an example? Wouter Lievens 09:10, 24 Apr 2005 (UTC)

... or the Lispkit Lisp meta-circular interpreter from Functional Programming: Application and Implementation which also contains a Lispkit meta-circular compiler. Yes, either of these would be more interesting but it is more important for the example to be easy to understand than for it to be interesting. Recursively specified interpreters may be interesting but they are not so easy to understand. -- Derek Ross | Talk 13:14, Apr 24, 2005 (UTC)

I myself find recursion a lot more readable than loops, but I guess that doesn't necessarily count for people who haven't been taught Scheme :-) Wouter Lievens 11:48, 20 March 2006 (UTC)

Attribution

The beginning of this article is copied from the FOLDOC entry of the same name. Is there some policy on attribution? If not, there should be. --BK 207.96.29.129 12:37, 8 September 2005 (UTC)

Where we use FOLDOC material we generally attribute it. I'm not sure why that hasn't been done in this article but it should have been. -- Derek Ross | Talk 14:09, 8 September 2005 (UTC)

I've assumed that the above claim is true and added the attribution and the cat.

Atlant 15:29, 8 September 2005 (UTC)

Bytecode interpreter

"...the source language is compiled into "F code" (a bytecode) which is then interpreted by an architecture-independent virtual machine." Shouldn't it say "architecture-dependent"? The bytecode is architecture-independent, the interpreter must be architecture-dependent... --Arny 21:08, 16 November 2006 (UTC)

Why? Interpreters can be run in interpreters. --Gwern (contribs) 21:17 16 November 2006 (GMT) 21:17, 16 November 2006 (UTC)

They CAN be, but the way the sentence is worded now, it says that all virtual machines are architecture-independent. That is obviously not true. I suggest that you just drop the qualifier and say "... which is then interpreted by a virtual machine." 66.32.88.47 21:23, 13 August 2007 (UTC)

Right, since nobody seems to object, I'm going to change it. 66.32.15.77 00:28, 17 August 2007 (UTC)

Evaluate

This has nothing to do with Evaluate yet theres a redirect! Jamhaw 20:04, 31 January 2007 (UTC)jamhaw

AST Interpreter

This and surrounding sentences seem to imply that an AST is better than bytecode: "Thus, AST has been proposed as a better intermediate format for Just-in-time compilers than bytecode". The reference is for a thesis and returns a 404. I would humbly suggest that an AST is not better than all bytecode, but rather an AST might be better than some bytecodes for certain optimizations. Surely, this argument can only be made if you weren't to improve the bytecode to include the missing information that is necessary for the optimizations in question. —Preceding unsigned comment added by 75.33.235.210 (talk) 17:17, 24 December 2008 (UTC)

As a somewhat expert of the field, I removed the section on advantages of AST-based interpreters, by providing a much better reference proving the opposite. Here's the removed text:

An AST-based Java interpreter, written in Java and reusing this, has been proved to be faster than a similar bytecode-based interpreter, due to the more powerful optimizations allowed by having the complete structure of the program, as well as higher level typing, available during execution.

I read the thesis, and the comparison is completely invalid; moreover the thesis does not talk at all about optimizations allowed by AST over bytecode (that's done only in Franz's paper). The interpreter is written in Java and is not optimized (as acknowledged in the thesis in some places, like intro of Sec. 3.3 and 3.1.1) and this already invalidates the comparison (unlike what is argued there). Variable lookup is performed through a symbol table in both interpreters (even the one for bytecode); the interpreter for ASTs is a meta-interpreter, i.e. it reimplements features of the interpreted Java through features of the host Java system, which gives it an unfair advantage which would disappear in a realistic implementation. Stacks used (including the operand stack) are based on the synchronized java.util.Stack - that alone is completely crazy. Optimizations described in SquirrelFish only work for bytecode, but their impact would be irrelevant in such a slow implementation, and very relevant for a real one.

I'm leaving the reference to Franz's paper (A Tree-Based Alternative to Java Byte-Codes) there, even if I believe it is irrelevant, too, in contemporary practice. Still, the proposal makes sense. However, benchmark results of that paper are invalid, if only because of the usage of arithmetic rather than geometric average in Table 2 (using the correct average actually gives different results when I compare IE and Juicy). There are probably better papers from him on using ASTs, but I've no time to search for them, and he abandoned the field anyway. --Blaisorblade (talk) 03:08, 6 August 2010 (UTC)

Advantages vs. disadvantages

i've incuded a article of advaantages/disadvantages of intrpreter which is simple for average user to understand and relevant to waht people expect to find b/w interpreter and compiler...
But this article is not fully complete ...
So kindly add new items to this article ... regards
--gursimar singh mohar 20:06, 26 December 2009 (UTC) —Preceding unsigned comment added by Simar mohar (talk • contribs)

I believe this section, that was added by a single user (albeit somewhat cleaned up by another well-meaning user) should be deleted. It is unsourced and somewhat arbitrary, and amounts to essentially original research and synthesis. WikiDan61^ChatMe!_ReadMe!! 17:07, 4 January 2010 (UTC)

This is surely not true currently - at least it is not original research but folklore (I wouldn't reference it if I were writing a paper). I didn't look (yet) at the history to see if there's any relation with what you discuss. --Blaisorblade (talk) 03:14, 6 August 2010 (UTC)

An anonymous user (68.197.139.156) added a paragraph (compare the delta) on Nov. 13, 2012. I considered fixing the grammar, but decided to delete it. Reasons:

1. The intent and role of this paragraph are not clear (to me).
2. There are some minor factual errors. At the very least, some sentences are misleading.
3. The paragraph duplicates other parts of the article:
   • It redefines an interpreter (orig. def. in 1st paragraph of article).
   • Efficiency is covered in the Efficiency subsection.
   • Portability is covered in the Distribution subsection.
   • The Java example is covered in the introduction.
   This leaves no real content to this paragraph.
4. Some sentences are copied almost word by word from the referenced book (Computer Science Illuminated, accessible via Google Books). This book does not seem to be under a free license. The quotes are not clearly delimited and marked as quotes. Examples:
   • Article: “An Interpreter is a program which translates the source […] and executes it statement by statement.”
     Book: “An interpreter is a program that translates and executes the statements in sequence.”
   • Article: “Translation […] is followed by immediate execution.”
     Book: “[The] interpreter translates […] and then immediately executes the statement.”
   • Article: “This process is more complex which makes interpreted programming languages to run slower compared to languages that are compiled”
     Book: “Because of the complexity of the software interpreters, programs in interpreted languages usually ran much more slowly than compiled programs.”
   • Article: “compiled high level language can run on computer that has appropriate compiler for that specific high level language.”
     Book: “A program written in a high-level language can run on any computer that has an appropriate compiler for this language.”
   • Article: “Java […] is compiled into standard machine language Bytecode”
     Book: “Java is compiled into a standard machine language called Bytecode.”

— Latk (talk) 01:46, 31 December 2012 (UTC)

information missing

Isn't some kind of interpreter also used when dealing with natural language input to computer programs? This aspect does not seem to be discussed in the article. —Preceding unsigned comment added by Skysong263 (talk • contribs) 18:01, 22 March 2010 (UTC)

Needs a lot of fixing

There's a number of problems I can see with the article:

• It hasn't got a clear distinction between compiling and translating to a bytecode. The big difference is that compilatrion does overall semantic analysis not just syntactic analysis.
• There are no proper inline citations for most of what is said, it seems more like peoples thoughts.

In particular sections

• In the leader 'executes source code directly' gives no clear picture of what that is supposed to mean. Does it mean reads the text and does actions based on what iut reads immediately?
• It talks about 'some translation work like compilers' which blurs the distinction.
• In 'Bytecode interpreters' Forth is just translated, it is not compiled.
• Bit about control tables is stuck in for no good reason and confuses things.
• In 'Bytecode interpreters' Forth is just translated, it is not compiled.
• 'Efficiency' and 'Advantages and disadvantages' just talks about slower execution and faster debug cycle. With a compiler many of the bugs are caught at compilation time rather than one at a time by debug. That is why it takes longer before it starts executing the first time.
• In distribution things like pcode, Java, .Net and others produce a bytecode that can then be interpreted or translated into machine code for any computer.
• The 'Execution environment' bit is rather confused or wrong.
• I haven't the foggiest what the bit about 'Abstract Syntax Tree' is about. I think it is confused with compilation.
• In the 'Just in time compilation' .Net translates whole modules to machine code and caches the result, it does not typically go in for JIT as it is used in Java though it is not compiled to machine code in advance and the bytecode is not interpreted.
• There should be a disambiguation page for interpreter pointing to language interpretation, this article, the punched card and any bands etc with the name and any extra info about punched card interpreters moved to the appropriate article.
• There is a second meaning of interpretation section stuck for no good reason at the bottom.

Dmcq (talk) 10:00, 11 May 2010 (UTC)

I see now That there are Forths that do optimised compiles rather than just producing threaded code, why anyone would want to do that for a write only like that I don't know. It is not though a good example of compiling for the article I believe. Dmcq (talk) 10:05, 11 May 2010 (UTC)

Citation and Non Sequitir

At present this article does a rather inadequate job of inline citation (see other users above me). It also has other issues with citation in a more practical sense. Even when a source is included at times it is included without contextual information and so the information presented is less then useful. A very important example of this occurs when the article gets to the LISP section and mentions "McCarthy". The first time the name is reference it is done without any context who McCarthy is or why one should care what he has to say. I could add "Donges" says to various articles and the rightful response would be "Who is Donges? Why do I care what he has to say. Now it may be that McCarthy is a well known expert in some field. That material still needs to be there to suddenly start referencing him as this is an Encylopedia article not a 1specialty manual. By way of a parallel example, I would not include a statement in an article about the C program attributed to Ritchie without at least at first indication of whom he was. To read at present an individual without computer background reading the article may think that McCarthy refers to former U.S. Senator Joseph McCarthy and honestly I do not really care what suprises Senator McCarthy about LISP. — Preceding unsigned comment added by 98.237.41.200 (talk) 07:31, 27 November 2011 (UTC)

Merger proposal

Although I prodded Self-interpreter as OR, Loadmaster suggests merging it here (which IMO is an acceptable alternate to deletion). Thoughts? All the best, Miniapolis 00:23, 25 February 2014 (UTC)

Dead link in one of the reference

In notes and references, the 7th reference, "Terence Parr, Johannes Luber, The Difference Between Compilers and Interpreters" no longer works. It results 404 error. — Preceding unsigned comment added by 36.72.217.31 (talk) 13:24, 7 November 2019 (UTC)

Not satisfied with first sentence

The first sentence makes it sound as if the CPU is executing instructions that haven't been compiled into machine language, and that's impossible. The CPU is only executing the interpreter. The interpreter process, running in the CPU, reads and maps the code to compiled routines within the interpreter, thus calling/executing machine code. The script or code here acts like data, and just triggers the execution of compiled code.

@ 2A00:23C4:B49E:CB01:605C:7BC9:D409:E883 (talk) 17:34, 14 November 2023 (UTC)

Wiki Education assignment: Linguistics in the Digital Age

This article was the subject of a Wiki Education Foundation-supported course assignment, between 15 January 2024 and 8 May 2024. Further details are available on the course page. Student editor(s): Kamrynley (article contribs).

— Assignment last updated by Kamrynley (talk) 17:04, 20 February 2024 (UTC)