On Oct 13, 2010, at 11:15 PM, Mathew Kurian wrote: > As long as the processor can only read only numbers (binary), Racket cannot > be interpreted by the machine before being translated into another language > such as Assembly. Assembly is then translated to numbers or binary/machine > code If that is the case, Racket has to be an interpreted language since it > is layered on Assembly.
That's not a useful definition: under that definition, EVERY programming language is an "interpreted language". The traditional definition I was brought up with was something like this: * A compiler translates a complete high-level language program into a complete machine-language program, which can be saved to be interpreted later directly by the hardware. * An interpreter looks at one statement/operator/whatever at a time, and rather than generating machine-language to save and run later, it DOES that statement or operator immediately. Even then, there was no such thing as an "interpreted language", since ANY language could be implemented with a compiler or with an interpreter; there were only "interpreted implementations" and "compiled implementations". Anyway, this distinction has gotten even blurrier in the past thirty years due to several innovations: * Microcode and nanocode: even so-called "machine language" isn't actually interpreted by the hardware; each machine-language instruction actually stands for a sequence of statements in a still-lower-level language, which are interpreted by hardware. Sometimes there are actually two levels of this: machine language becomes microcode which becomes nanocode which is interpreted directly by hardware. * Bytecode and p-code: a complete high-level-language program is translated into a fairly-low-level form which is, however, not specific to any particular hardware. This bytecode can be saved and transferred from one computer model to another. When you want to run it, you actually run a "bytecode interpreter" which is faster than interpreting source code, but not quite as fast as interpreting machine code on hardware. * JIT (just-in-time) compilers: A modification to the "bytecode interpreter" above: when the interpreter sees something potentially time-consuming (like a loop), it actually translates the whole loop into machine language and then calls this machine language rather than interpreting each step of the loop itself. * Smart pipelined processors: A modern microprocessor may actually look at the next several machine-language instructions, analyze them, and re-order or re-organize them to take better advantage of its pipelined architecture. So your question, which was somewhat meaningless forty years ago, is even more meaningless now. Stephen Bloch [email protected] _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
