|WikiProject Computing||(Rated C-class, High-importance)|
|The content of Self-interpreter was merged into Interpreter (computing) on April 2, 2014. For the contribution history and old versions of the redirected page, please see ; for the discussion at that location, see its talk page.|
- 1 This page does not explain what in interpreter IS
- 2 Why is an interpreter defined as a computer program?
- 3 JIT
- 4 The Example
- 5 Attribution
- 6 Bytecode interpreter
- 7 Evaluate
- 8 AST Interpreter
- 9 Advantages vs. disadvantages
- 10 information missing
- 11 Needs a lot of fixing
- 12 Citation and Non Sequitir
- 13 Merger proposal
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)
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)
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)
- ... 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)
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 184.108.40.206 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)
"...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." 220.127.116.11 21:23, 13 August 2007 (UTC)
- Right, since nobody seems to object, I'm going to change it. 18.104.22.168 00:28, 17 August 2007 (UTC)
This has nothing to do with Evaluate yet theres a redirect! Jamhaw 20:04, 31 January 2007 (UTC)jamhaw
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 22.214.171.124 (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:
- 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. WikiDan61ChatMe!ReadMe!! 17:07, 4 January 2010 (UTC)
An anonymous user (126.96.36.199) added a paragraph (compare the delta) on Nov. 13, 2012. I considered fixing the grammar, but decided to delete it. Reasons:
- The intent and role of this paragraph are not clear (to me).
- There are some minor factual errors. At the very least, some sentences are misleading.
- 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.
- 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.”
- Article: “An Interpreter is a program which translates the source […] and executes it statement by statement.”
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.
- 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 188.8.131.52 (talk) 07:31, 27 November 2011 (UTC)
- Trees Versus Bytes, BComp Honours thesis by Kade Hansson
- Dale & Lewis (2012). Computer Science Illuminated. pp. 295–297.