>Sorry, don't agree. VFP is not an interpreter. An interpreter, such as FoxBASE, "interprets" text and executes that. In the instance of FoxBASE it was possible to produce tokenized p-code via foxpcomp.exe and distribute the FOX files (rather than the PRG files).
>

Your implication that "interpretation" can not involve an intermediate step (eg. p-code generation) is false.

>Normally, with a native compiler, the source code (text) is translated into an intermediate code (usually tokens and referred to as p-code), prior to being sent to the emitter to be converted to machine code. The tokens represent offsets into a table containing the addresses of the entry points where the compiler store the language element in machine code.

>In VFP (and all versions of FP since 2.0), the emitter phase is omitted and the p-code (tokens) are output. Here the tokens represent the offset into a table that contains the entry point in the run-time library. Of course, FPD did have an emitter that translated the code into machine code. The files, however, that it produced were huge, and I don't really think that even to-day, we'd want to deal with files that large.

The fact that I have been (successfully) running some VFP 6.0 "object modules" in the VFP 7.0 environment lends little credibility to "table offsets" and "run-time library entry points".

(You also seem to be implying that FPD was a "machine-code" compiler; false again).

Gabblefarb notwithstanding, a "computer" cannot execute p-code directly; it can only execute machine code. In the case of VFP and other applications that are "compiled to p-code", a (run time) "interpreter" is employed to "execute" this p-code.

You may not "like" the definition, but that is the definition of an "interpreter" (according to MS and any number of other "public" sources).

"FoxPro does not generate native code. It is an interpreter ..."

MSDN.