Doug,

>Whoops! Sorry that I misunderstood you. (Oh great, here comes the guilt again.. <g>)

If this keeps up, you're soon gonna owe me several rounds at the next conference. :-)

>However, isn't that kind of what you really are suggesting? If you remove a feature that some other feature might depend on it seems to me that almost immediately you're in the swamp of unscrambling the internal relationships that have taken years to put together.

I don't think I'm talking about a huge number of limitations.

>The introduction of random, automatic, in-the-field reconstruction (via command line switches?) so increases the number of permutations that you quickly reach a point of inherent instability.

I have no idea what you're talking about.

>Then who supports such a beast?

Who supports MTDLL?

>let me ask this and perhaps clear things up: Who makes the decision on what features in FoxPro to include? We all agree that developers decide what features of FoxPro to include, right?

Who made the decision on what to cut from MTDLL?

>Again, I think you have a great idea. I honestly don't think it's practical.

Let's approach this from another angle by taking a specific scenario: Super-fast UI for an n-tier-architected application. No direct data access to tables in the front end, but only through middle-tier business objects and back-end data components.

Leaving out the data commands like USE, SELECT, etc., what VFP features would have to be eliminated and what new ones would have to be added to be able to pre-process the VFP code into C++ code, then compiled native so as to not require a VFP runtime on the client?

Obviously, macros would be eliminated for that scenario. What else would have to go for that to be possible? Might not be a very large list. We would need strong typing, and some other additions, I'm sure. See where I'm headed in my thinking (dreaming)?