>Peter
>
>
>>...Terry rather I'd like to add your 'best' argument. So, now we have three nice arguments. No, let's split up number two, so four arguments.
>>1) It occasionally gives better performance (speed).
>>2) It occasionally improves readabillity.
>>3) It occasionally improves code maintenance.
>>4) It occasionally is the only way to accomplish a task.
>
>
>The first three points are equally appropiate for using EVAL() and cannot therefore be used as arguments for using macro substitution over using EVAL(). i.e.
>
>EVALUATE() ...
>1) It *usually* gives better performance (speed).
>2) It *usually* improves readabillity.
>3) It *usually* improves code maintenance.
>
>Your forth argument cannot be changed to EVAL()'s benefit since thats part of the point of the discussion. I still say that macro substitution is a legitimate technique, as is EVAL(), and that it has its place when used appropiately and when required. WalterM gave a really nice example in this thread for appropiate use of macro substitution and Sergey has given good examples of when to use EVAL(). Its not a case of "either or".
>
>:)

Jos,
The help text on the macro command says nothing about eval(). The help text on eval() does mention the macro command. Funny inconsistency.
There's another item that needs to be mentioned here: 'Name expressions'. This is a phrase that's used in the help text to refer to expressions in commands/functions that specify a name, e.g. the name of a file, alias, table or field. Often it's okay to specify the name without the use of quotes. If you want to use a variable, it's necessary to prevent that the actual name of the variable is used as name. The preferred way to prevent that is to enclose the variable in parentheses. The mentioned reason is speed. Other reasons may be thought of, but there's no heavy penalty for those who want to use the macro command instead.
In the macro help text 'keywords' of commands are also mentioned. Their advice is: Whenever you want to parametrize a keyword of a command, use a macro. Name expression and eval() are not mentioned for that case.
In the evaluate() help text, the advice is to use eval() or name expressions instead of a macro, whenever possible. The only mentioned reason is, once more, speed. On the other hand, it's stated also that eval() is not rushmore optimizable. I found out that a SQL-query with a built-in macro is potentially still rushmore optimizable, since the optimization decision is made only after the one-time evaluation.

I still stick to this list:
1) A macro occasionally gives better performance (speed) than eval().
2) A macro occasionally improves readabillity.
3) A macro occasionally improves code maintenance.
4) A macro occasionally is the only way to accomplish a task.

But maybe you like this list more:
1) Macros are the only way to parametrize a keyword in a command.
2) Macros are only the second to best way to parametrize a name expression in a command.
3) When used as argument in a loop construction (like a DO WHILE and a SQL-query), there's a fundamental difference in the way that a macro and an evaluate() are handled. The functional requirement is therefore decisive.
4) Evaluate() is not Rushmore optimizable, whereas the use of a macro leaves that possibility intact.