>>>>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.
>
>To some extent you are both right.
>
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvcpp/html/msdn_c7pcode2.asp
>
>"P-code works by compiling an application into an intermediate code format that is much more compact than 80x86 machine code. At link time, a small engine is built into your application that processes the p-code into native machine code during run time. Although there is an associated reduction in performance due to the extra step of interpretation, some simple techniques can minimize this effect."

Len,

As I said, it's a matter of definition. I choose a stricter definition. The argument can be made either way. For example:

Question: Does VFP produce machine executable code?
Answer: No
Statement: Then it is an interpreter since it must "interpret" the tokens via its runtime library.

Question: Does VFP compile it's programs?
Answer: Yes
Statement: Then it is a compiler since it does not "interpret" the source code at run time.

In reality, I believe it's neither an interpreter nor a true compiler, but something else. From an abstract point of view, you can call it an interpreter or "something else". I'm a big believer in defintions. Applying precise one's wherer or abstract one's as necessary. Here, I don't feel that "interpreter" precisely defines what it does.