>>Jess,
>>
>>A few questions.
>>
>>> Majority of my colleagues here want VFP to be .Net language.
>>
>>First question, what is a .NET language? Is it a language that can consume .NET services? If so then VFP is already one.
>
>It should compile with CLR..

That's nonesense - you're saying that VFP should limit its behavior to the behaviors in the CLR environment. Say goodbye to everything in VFP that violates the intepreter model behind CLR. Or are you saying at the CLR should contain all the native constructs of VFP? If so, why is there a need for anything other than VFP?

NOTHING compiles with CLR. The CLR-compatible language compiler emits CLR p-code, which contains a very narrow set of behaviors. If you wish to treat the p-code of the CLR as the basis of building an interpreter, you end up creating something close to a beaded threaded interpreter model of language behavior, similar in philosophy to Forth. You essentially have to take all of the optimization going on inside of the VFP native interpreter that right now makes no concessions to the requirements of the codeset of a virtual machine code, and rethink them in terms of CLR expression. At the very least, with multiple levels of interpretation, the level of the VFP interpreter, which handles things like macroexecution, name resolution, name indirection, loose typing, free declaration of variables and properties, not to mention the embedded data language, and now rather than execute native code, reemit CLR p-code, which must be interpreted. We end up bulky and slow, and unable to offer any advantage over other CLR languages, because our interpreter model is at wide variance with the CLR interpretation model.

If I get a vote, I'd vote NO. But then, I'd like to sacrifice a lot of things that we perpetuate supporting backwards compatibility for streamlining; I've been told by people who know a lot more than I do that as long as our underlying interpreter behaviors stay much the same, we can keep considerably more backwards compatibility with adding great bulk (IOW, some of the new services are built on the code behind some backwards compatible features, so there's low cost to the backwards compatibility) but that all changes when we have to switch to think in terms of the CLR model of behavior.

Personally, I trust the judgement of people like Ken Levy and Calvin Hsia and Gene Goldhammer, who are determining what directions we can move in and keep the uniqueness of VFP, more than the wishes of a few, terrified developers who see the world is moving to a new model of computing, that might leave them behind, but won't change their mind-set out of the world of ten years ago.

Face it, Jess, you have to either evolve or die. Which is a personal decision.

I don't make the rules, I just play the game.