Nick wrote
> From the point of view of Stata's parser,
> what text within commands was born as -- as variable labels,
> as value labels, as common or garden text,
> etc. -- is irrelevant. The parser
> just sees a stream of characters and looks
> (in particular) for $ signs as signalling
> global macros.
>
> Here you want correctness of
> syntax to depend on meaning, or guesses
> at intent not content. My understanding
> is that that's a slippery slope to programming
> perdition.
>
> The point about variable labels is indeed an
> important detail.
>
> Perhaps it's fixable deep, deep within -graph-. We
> need a conVincing answer on that one from the
> experts. However, consider that some
> user-written graphics ados (some of mine,
> any way) often set up default axis titles from
> variable labels. Those variable labels are therefore
> interpreted _before_ -graph- is called. If this
> is a problem for user-written ados, it presumably
> also is for _all_ graphical ados.
Very true. I am actually very fond of the fact that, in Stata, macro
expansion occurs anywhere in the code. It allows to write snippets of code
on the fly and enables the calling of routines or evaluation of functions
dynamically at run-time.
The trade-off is that it is difficult to have a string of text characters
remain just that, a string of text. But this could possibly be overcome by
defining a special character which would appear to the screen and in
exported graphs as the dollar sign. Couldn't it?
In fact, the dollar sign problem bites more than just in graphs. I makes it
impossible to properly save variable labels, modify labels with -labvarch-
such as (after -collapse-ing data), etc., since any evaluation of `: var la
<variable>', within any ado, forces the interpreter to expand anything that
resembles a global. Very annoying to have to redefine labels again, and
again, and... A character special to the screen would be very useful.
> However, the problem works both ways. It must remain
> perfectly legal to refer to global macros
> when defining variable labels (or value labels).
> Empirically my guess is that this is not
> often done, but that's immaterial. It makes
> perfect sense!
>
> Nick
> [email protected]
>
> [email protected]
>
> > I realise my earlier email was imprecise. I am mostly lamenting the
> > mis-feature (IMO) that labels get evaluated as macros within
> > the internals
> > of -graph- even though they are not even macros to begin
> > with. Nor are they
> > passed as arguments by the user. Once a label is defined, it
> > should always
> > continue to be treated as a string literal, i.e. no macro
> > interpolation
> > should be done.
> >
> > The SMCL work-around works only in ytitle() or title()
> > options, it doesn't
> > work when setting variable labels, e.g.
> >
> > . la var xrus "{c $|}US per {c $|}CA"
> >
> > doesn't work the same way. It is not a serious nuisance
> but is still
> > unfortunate; it doesn't reward the overhead of having
> > diligently labelled
> > one's data.
Patrick Joly
*
* 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/
