Hi Ed,

>(1) You can't directly use macro expansion against an object reference or field; name expansion and evaluation both accomodate this.

No doubt that in these cases EVALUATE() is clearer. I merely wanted to point out that macro substitution can in certain situation be clearer and speed is not longer really an issue.
>And you can expand this utility to variable assignment by using STORE - while you can't legitmately say:
>
>(cMyVar) = SomeValue

Right, because "=" requires a variable, not a variable name.

>I tend to restate this as use macro expansion where you need to have VFP's command parser get involved in handling the resultant statement.

OK.


>Actually, you can use EVAL() in all but the SELECT statement.

You can. But SET FILTER TO EVAL() is not optimizable, unless you have an index on the EVAL() line. And this makes it rather useless, IMO.

>In general, the cost of EVAL() is high in loop/repetition conditions; the macro-expansion is performed once for the statement as a whole, and not executed against each iteration.

Nope. It's executed per iteration. But you have to know when VFP evaluates a line. A loop command like FOR is only evaluated once. Changing the TO variable doesn't affect the number of loops. A SCAN FOR condition is also only evaluated once, if it's optimizable, otherwise it's evaluated for each record.


>Within the confines of the loop, EVAL() is strongly preferable to macro expansion.

It's almost never the question of whether it is in a loop or not. Macro expansion is always the one that should be considered last.

Christof