>>>I agree, the fox database engine with dbfs is extremely fast. It would be cool if the database engine was available in other langauges much like the Access database engine is available to C++, Visual Basic. :->
>>
>>
>>Wouldn't that be great!
>>
>>Another extraordinarily powerful component of VFP that is often overlooked is it's macro substitution facility. You can literally write code that writes code, execute it on the fly, all within a distributed app. For *database* applications, this is super because generally you are passing a complex command to VFP's engine (thus, fast execution by the DB and GUI engines once the command processor has completed its part). However, as noted before, this aspect of VFP is equally frustrating (on the slow side) when you try to use numerically intensive algorithms in your app because VFP is an interpreted language.
>>.
>It's part of the price you pay for macro substitution. However, there's also another reason why numeric operations and iteration structures don't perform particularly well: the language is loosely typed. In a FOR...ENDFOR loop, depending on the terminating value, FoxPro has to manipuate up to four times the number of bytes (assuming an integer WORD) than a language that supports numeric typing.
>
>BTW, I've seen the remark, that VFP is an "interpreted" language. Strictly speaking, this is not correct. It's tokenized threaded pcode. Back prior to FoxBASE+ 2.0 it was a true intepreted language.
>
>George

I have my theories, but what is the definition of 'threaded p-code'? I usually thought p-code is basically like Java byte-code in that it is post processed (compiled) data which is in turn 'interpreted' by some highly optimized loop... I wrote a simple math interpreter that used this technique, and called it 'p-code', but had no idea what the term meant.

Peter