Statalist


[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

st: Stata tripping on braces


From   "Gabi Huiber" <[email protected]>
To   [email protected]
Subject   st: Stata tripping on braces
Date   Mon, 28 Jul 2008 12:59:30 -0400

Hello Listers,

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.

Gabi
*
*   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/



© Copyright 1996–2024 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index