>There is no way you could process commands and/or functions in a string without a compiler. However, since the EVAL() function is limited to evaluate expressions, the runtime compiler does not have to be as advanced as the VFP compiler as a none of the commands (only functions) can be executed with EVAL(). This might also be the explanation why EVAL() is about twice as fast as &.

That makes sense.

>Yet, now you're talking to take the whole language to a higher OOP level and indirectly you're saying you want to omit the native SQL syntax of various commands for local data. How would you continue support for the SQL DDL and DML ?

I don't want to eliminate it at all. But as I have said in other threads, I think we need an SQLExecute function that works for native data, so we can construct the SQL string and pass it to the function. This is how many other languages support SQL.

>>We only have to use & in ALTER TABLE to get around a goofy literal driven syntax for creating tables. In this case, & is not powerful, it is simply a crutch to help us get by with a goofy language.
>
>Yet, you're talking about SQL ! I'll bet there are whole tribes of people who want to see more SQL support in the language.

As do I. I would just like a way to use the SQL without to resorting to & to run parameterized statements. See above.

>>For a language that claims to be object oriented, we lack a lot of object ways to do things, and that's why we currently need &.
>
>Though I do not reject this statement, I don't think that even if the language was fully OOP, the need for & would entirely disappear.

Maybe not. But 98% of the things that people use it for would be provided for. _All_ of the things I use it for would be taken care of.