>>Don't mean to be picky here, but, by definition, VFP most definitely is not an interpreted language. It produces tokenized threaded p-code. An interpreter is forced to re-evaluate the source code each time the program loaded. While this does happen with macro expanision, this is the only time such occurs. I know you know this, but I just wanted to clarify the subject for those who do not.
>
>"By definition", it's not a "compiler", since a compiler produces "machine code". That only leaves "interpreter".
>
>That fact that a language (ie. Java, xBase, Lisp) produces (intermediate) p-code, byte-code or whatever, does that negate the fact that it is still an "interpreter" (ie. no machine code).
>
>If "interpreter" is not sexy enough, you can always try to convince people that VFP produces "machine code" for the VFP "virtual machine"; that's the tack VdB and Java take (among others).

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).

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.