>The definitions I always used were that an interpreter converted raw source or tokenized code at run-time into machine instructions. A compiler linked in library modules and converted source into machine code so that very little or no intepreting was done at run-time.
>
>Is this wrong?

You're talking about degrees here.

Typically, "compilers" don't "link"; linkage editors do that, unless you want to contrast static vs dynamic linking ... in either case, neither is done by the compiler. And the "classic Compilers" produced "machine code"; it may be more accurate to call what VFP does "pre-processing" (when it creates FXPs).

And if "no interpretation" is occurring, then the assumption is that we're executing machine code directly on the processor (ie. the hardware).

If we're converting "code" to machine instructions at run-time that is not "interpreting"; it's JIT compiling (and execution).

The comparison of an interpreter to a virtual machine makes it more clear (IMO). A "real" processor only executes machine code; a virtual machine (ie. interpreter) "executes" p-code. The "real" processor may "call" a channel program; the virtual machine calls functions in DLLs/FLLs.

The run-times of Java, VB and Vdb (for instance) are called virtual machines, though typically you won't find the term "virtual machine" in the common literature; you find "interpreter".

I see all this as information that is easily available from any number of sources.

I don't see what you're saying as "wrong"; you simply seem to be addressing a number of different issues at the same time that encompass more than simply "interpreting".

The "definition" that I see most frequently is that unless the "generated code" (ie. object code) is capable of being executed "directly" by the (hardware) processor, you're dealing with an "interpreter" (ie. "layer", run-time, virtual machine, CLR, whatever).