>3. When using a VFP command window in your application, you'll have to use &.

You can now use ExecScript for this. And in version 6, you could use FILETOSTR and COMPILE, but I suppose that's beside the point.

I guess the only reason either of these methods would be any better than & is that they aren't as fragile.

>4. EVAL and & are commands of the same family. EVAL() is more limited than & and only about twice as fast.

Well, they serve difference purposes. Evaluating an expression is different than executing a command.

> Both commands need to interpretate the argument and proces it. For both commands you'll need a runtime compiler.

Are you sure about that? Not that I am disagreeing necessarily, but this is a topic I would like to know more about. EVAL doesn't have the power to run any uncompiled code, only to decide when to call a function that already exists.

>5. both EVAL and & are very valuable in frameworks there where commands (or better: clauses of commands) depend on a given situation.

This is really the situation I was asking for examples on.

>Though I think I know your objection against & (It attempts developers to write bad code),

You're correct. That's the biggest reason. But not the only one.

> I dont think this objection is true; it's application lies in the hands of the developer. I don't think that the omission of & from the language will result in less bad coding.

I disagree. I have had to work through other developers' code where there was so much macro expansion going on, you couldn't tell what the hell was happening. Passing the name of a command as a parameter to another function is a crime worthy of punishment by troutslap. I've actually seen this and many other crimes committed using & as the weapon.

>Personally I mainly use & for being able to add clauses to existing commands. There are numerous cases where VFP does not allow name expression and your only resort to solve the problem nice and clean (thus without long DO CASEs OR IF structures) is by using &.

Right, but I view this not as a glorious use for &, but as a shameful workaround for big gaping holes in our language. I am of the opinion that ALL VFP commands should take named expressions instead of literals. But until then, we'll have to keep patching those holes with &.