He's already done it. Using a very early version, Markus Winhard demonstrated processing speed faster than native .Net languages (while giving the correct result) in a contest sponsored by the German magazine DotNetPro. Here's the translation of the German article: http://translate.google.com/translate?u=+http://indot.net/dotnetprocontest07/dotnetprocontest07.html&langpair=de|en&hl=en&ie=UTF-8&oe=UTF-8&prev=/language_tools Markus used the TLOCAL implementation added by Samuel to the Compiler as part of his solution, if I remember correctly.

Hank


>Oh, so now Samuel is going to not only keep VFP alive after the vendor has kicked it to the curb but actually extend it? Single handedly? Now I've heard everything ;-)
>
>>Hi Mike,
>>
>>have you read the eTecnologia announcements of features in the various releases? There have been evolutionary changes to the VFP language announced with nearly every release, I think. And Samuel has announced publicly that there will be more (some of which I have noted in various posts). So I'm not sure what deadend means here: this is a living, growing language. How is it a deadend?
>>
>>Hank
>>
>>>>>Why target only VFP developers? Who else would want a VFP compiler at this point? Do you think new people are coming to the language? -- looking around at the available options and saying, "Yup, that's the one for me!" That hardly seems likely.
>>>>>
>>>>>I get what you are saying about the strengths of FoxPro. As you say, there are DOS apps still running and working. But why would those people want a .NET compiler?
>>>>
>>>>I have a client for whom I maintain a DataFlex application. (Anyone remember DataFlex?) I would like to convince them to rewrite the app using a large FoxPro application that I own as a base. I'm worried about the question:
>>>>
>>>>Why would we move from one deadend language to another deadend language?
>>>>
>>>>A VFP.NET would remove that worry.
>>>>
>>>
>>>It would? Maybe there is something fundamental I am missing about eTecnologia's product. I thought it was a tool to compile VFP code to .NET. (Is that incorrect?) I don't see how that makes VFP any less deadend.