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.