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

st: RE: set literalvarnames on

From   "Nick Cox" <>
To   <>
Subject   st: RE: set literalvarnames on
Date   Wed, 12 Feb 2003 23:02:08 -0000

Clyde Schechter
> Assuming it could be implemented by Stata Corp. in a 
> reasonable way, I
> would definitely want, and use, a feature which permitted me to ban
> abbreviated variable names.  I completely endorse Glen 
> Waddell's concerns
> about the way abbreviated names can introduce 
> difficult-to-track-down
> errors.  In past postings to this list, I have also 
> proposed that the use
> of uninitialized macro names as null strings be banished 
> (or, at least
> optionally banished with a setting).  The two practices are 
> conceptually
> related, and probably should be combined as a single 
> setting that does
> both.  It is hard to imagine a programmer who would want 
> one but not the other.

I don't think it helps -- at least as a matter 
of practical Stata lobbying -- to lump these two 
issues together at all. The first has been well aired 
in this thread, and so far the picture is that several 
people say they want it, but this is all no more than 
wishlist item until Stata Corp says how difficult it is
-- and indeed whether they think it is a good idea, 
when all implications and side-effects are spelled out. 

The second is the rule that if Stata encounters 
the statement  

. local mymac "`mymac'<stuff>" 

then `mymac' evaluates to empty if not previously 
defined. To put it another way, it is not an error
to refer to a non-existent macro, or one that is empty. 
(In Stata's ontology, the two states of non-being 
appear well nigh indistinguishable to the user.) 

A parallel construct for globals is also 

One of the most common ways this arises 
is within a loop as a way of building up possibly very 
long strings. 

Invoking this rule is entirely avoidable in terms of what you write 
by explicit initialisation of macros to empty strings. 
As said, that doesn't make much difference to Stata, but it does 
protect you against one kind of bug. 

You can dislike this language detail on any sort of 
grounds whatsoever, but the likelihood of it 
being abolishable -- or even settable -- is, 
I would guess, zero.  

Again, I believe that the issue is not just a matter of what 
users type and how it is to be interpreted by 
Stata. It is one of how Stata interprets syntax, 
from wherever it comes, including Stata's own 
programs. And I surmise that setting this off 
could only be done with a major side-effect 
that many, many programs would be broken. Your 
Stata would be unusable. 

*   For searches and help try:

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