Fred Wolfe
>
> Nick writes further
>
> >A quite different comment is that it's not clear
> >why you need the { } around the macro name in that position.
>
> It is not clear to me either, but running the program
> without braces produced:
>
> - forvalues j = 1 / 2 {
> - forvalues k = 1 / $catvar`j'_totline {
> invalid syntax
> di "`k'. ${catvar`j'vname"`k'}"
> r(198);
>
That was a red herring of mine. Fred does need them
for what he is doing.
Imagine you are Stata. You try to make sense
of a command line from left to right, but following
your punctuation rules, including parsing
on spaces. Given
forvalues k = 1 / $catvar`j'_totline {
the tokens
forvalues k = 1 /
all make sense. So far, so good; this is fun. Now
the next token starts with "$", evidently the start
of a global name. To you the global name is maximally
$catvar
because "`" signifies the start of a _local_ name:
you must change your mind about what you are interpreting.
Now the global
$catvar
is not known to you, so you just blank it out here.
That's the standard rule for undefined macros.
The local
`j'
is known to you. It has contents "1". The next characters
are
_totline {
and the line as a whole now is
forvalues k = 1 / 1_totline {
which is illegal. Squawk!
To put it more concisely: what we need is to insist that
Stata evaluates `j' before evaluating $catvar`j'_totline and that
what's the braces do.
But as said, Stata can get confused by those braces
and they should be put on a different line.
Having said all that, I find that I use globals very
little in programming. That's partly a question of
style, but there are some arguments for it.
forvalues k = 1 / `catvar`i'_totline' {
would cause none of these problems, I think.
Nick
[email protected]
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
