No that's not at all what I meant. The CLR is like a runtime that a language sits on top of. Think of it like the VFP runtime that has yet another layer on top of it which is the language. The language has to support whatever the runtime provides for common structures and constructs. Any other functionality beyond what that runtime provides must be built by building ontop of the runtime (ie. recoding so it works in runtime code as opposed to native code as VFP is). The language implementation can do whatever it wants from there on out, but you it has to be recoded or at the very least wrap existing functionality via passthrough calls. Building the base language is probably something that is quite feasible, but expecting a large part of the VFP language/structure to migrate that way is just not realistic due to resources.

The whole point of the CLR is that the languages sitting ontop of it should be portable. So in theory at least if there ever is a Unix version of the CLR your code runs unchanged regardless of which language it was written in. I can't see that happening really but that's one of the key points .Net makes.

+++ Rick ---


>I 've been watching the whole discussion conserning the CLR.Many seem to have the belief that in order for a language to participate in it must abandon its idiosyncrasies. But this is really very strange to be truth, because this would mean that every data manipulation enabled language like Cobol for inst. should loose its data manipulation language, if it wants to participate... Well if this is truth then M$ has not open the doors for new languages to participate to its vision but rather closed the doors for any differencies and opened it for ungly uniformity
>
>Dim.
>
>>Evan,
>>
>>>All I want is the option to compile to the CLR. It would go something like this. I get full VFP with backwards compatibility with a normal compile otherwise I can compile to the CLR which will have some restrictions (and some benefits)
>>
>>OK, then start the ball rolling with a list of Syntax that you would include/exclude in the CLR-compatible version. Specifically, how would you handle the data manipulation commands?
>>
>>What are your MSIL/CLR replacements for the following:
>>
>>USE mytable ORDER something
>>SEEK cMyVar
>>REPLACE (cField) WITH DATE() WHILE cKeyField = cMyVar
>>CREATE SQL VIEW whatever....
>>
>>
>>... just for starters. What would you do with those commands to make them work on the CLR?
>>
>>That's the kind of discussion we need -- specific ideas about how to make VFP run on the CLR, and what the trade-offs are in available syntax and performance.
>>
>>>True the direct gains would be for the developer. Oh.. here's one. What if someone could download your tiny VFP exe and run it right away without having to download a 12meg runtime.
>>
>>That's one for the plus column.