I guess you are right in principle and that you have unearthed a
limitation, arguably a bug, in Stata. But that's for StataCorp to
confirm.
But in practice there seem to be no grounds for using braces around
macro names whenever there is no reason to force a particular order of
evaluation and no ambiguity. On that and on other grounds this trap
looks easily avoidable.
Nick
[email protected]
Gabi Huiber
I've mentioned the problem described below in a different context
before, and some of you have given it their best shot. But it is
stubborn and inexplicable so I will take the liberty of bringing it up
again:
Stata will execute this code (1):
foreach z in msg sub {
forvalues i=1/${${z}_filesnum} {
local ${z}_file: word `i' of ${${z}_files}
local ${z}_market: word `i' of ${${z}_markets}
}
}
But not this one (2), in a different do-file:
forvalues i=1/${mergecount} {
local w: word `i' of ${bigmerge}
foreach z in msg sub {
local spot: list posof "`w'" in global(`z'_files)
local `w'_`z'_file=word `spot' in "${`z'_files}"
di "``w'_`z'_file'"
}
}
It trips here:
. forvalues i=1/${mergecount} {
program error: code follows on the same line as open brace
r(198);
I dispute that this is a program error. I think that Stata is at fault
on this one. It reads the open brace after $, whose job is simply to
frame the mergecount global name, as if it were the brace that foreach
calls for, whose job is to frame the code that follows.
Stata should be smarter than this. It should wait for any brace
adjacent to a $ sign to close, and only then start looking for the
brace that the foreach syntax calls for. And it sometimes does act
like it should, because code (1) runs fine, just not always.
The reason for this inconsistency escapes me. I would appreciate any
help.
*
* For searches and help try:
* http://www.stata.com/help.cgi?search
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
