Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

[no subject]

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

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. 

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! 

[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.

*   For searches and help try:

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