Nick,
Thank you for your thoughts. Of course you're right in principle about
the proper grounds for using braces. They are clearly only needed when
you combine macros between themselves or with other things.
But I have two other reasons for using them by default. One has to do
with automatic parsing of files. The braces keep things like
search/replace from wreaking havoc. The other is weaker still. I have
come to acquire a set of habits that over time have been shown to
minimize annoying small errors. The use of braces is one of them.
That said, I put this patch on the block of code (2) below, and it ran fine:
local foo=${mergecount}
forvalues i=1/`foo' {
[...]
}
Gabi
On Mon, Jul 28, 2008 at 1:45 PM, Nick Cox <[email protected]> wrote:
> 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/
>
*
* 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/
