Bookmark and Share

Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: st: Wishlist for Stata 13


From   Nick Cox <njcoxstata@gmail.com>
To   statalist@hsphsun2.harvard.edu
Subject   Re: st: Wishlist for Stata 13
Date   Thu, 10 Jan 2013 17:48:55 +0000

Clyde has explained his proposal very carefully and cautiously, but my
guess is that this is not going to happen as he wishes. There are
several compelling reasons for that. But the principles he raises are
very interesting and pervasive, which is why I want to comment.
Naturally this is just my take, and the decision is totally
StataCorp's call.

1. I agree, as a user who also programs, that particularly in
developing code a frequent small error is to type the wrong macro
name. If I had a dollar for every such mistake I made I could have
retired long since. In practice, however, that is almost always
exposed quickly because something does not work, and very early in
their programming history Stata users learn that this is a common kind
of mistake.

2. I don't think what is common or standard in programming languages
generally is necessarily germane. Stata's macro handling facilities
are in essence facilities for some kinds of string manipulation, and
in string manipulation nothing is more fundamental than the empty
string; it's the natural and often useful limiting case.

3. In a sense, Stata conflates what might otherwise be regarded as two
distinct situations: a local macro that is undefined and a local macro
that is defined but happens to be empty. We can argue whether that's a
good idea, but it does imply that Stata has no way to tell apart (a)
the problem here of accidentally undefined macro names (b) macros that
are undefined for good reasons (think of the local macros that could
exist but don't because -syntax- didn't see -if- -in- -weight- and
many or all of the possible options to a command) (c) macros set to
empty because that is what the programmer wants, at least in some
circumstances. Clyde wants to make (a) impossible but the problem is
to how to do that without undermining (b) and (c), which are both
really, really useful.

3. Even with the cautions Clyde outlines this proposal would break far
too much code for it to be a practical proposal. It's not really a
case of experienced user-programmers learning to adapt to the change
or use -version- control. It's a case of everyone else using a program
or a do-file written largely or entirely by someone else that didn't
include a -version- statement (which in the latter case means most of
them). I shudder at the thought of a large new class of questions on
Statalist emerging on this change.

4. Stata has done this already by introducing string scalars. You can
use string scalars for string manipulation in at least some
circumstances when you don't want to be bit by this.

5. Alternatively, you can always program defensively by making
yourself test what should be true, e.g.

if "`macname'" == "" {
          di "macname undefined"
          exit 999
}

6. I don't think the option idea can fly. Users might want to set an
option as regards their own code, but this is the lesser problem.
Typically users will not want to be constrained to using code written
in the style that they themselves prefer.

(On Clyde's last point, I think he is right on 13 and 14. As the Tao
says somewhere, "Those who know do not say. Those who say do not
know." But as the Tao doesn't say anywhere, I don't know the exact
release date of 13 and am guessing too.)

Nick

On Thu, Jan 10, 2013 at 3:53 PM, Clyde B Schechter
<clyde.schechter@einstein.yu.edu> wrote:
> I wish the behavior of local macros were changed so that referencing a macro that has never been defined is an error, rather than treating it as an empty string.  I with I had a dollar for every time I have made a typo in a macro name.  (I haven't actually studied it, but I have the impression that local macro names are higher risk for typos because you have to displace your fingers from the home keys to reach the ` key.)  If you are lucky, the mistyped macro's being interpreted as an empty string will lead to a syntax error, as for example when it is being used to specify a varlist in a command for which varlist is not optional.
>
> But often enough, the empty string leaves you with something that is legal, but wrong.  A good example:
>
> by `farname1' `varname2' sort: .....[whatever]
>
> will lead to perfectly legal syntax if `farname1' is a typo for `varname1' and is undefined.  But it leads to results other than intended.  If you're lucky the mistake will be immediately obvious in the results.  But sometimes you don't find out until several do-files later when results based on that start to look whacky.
>
> Most programming languages enforce the principle that you cannot reference a term that you have not declared or defined (unless it is a language keyword), so the compiler or interpreter protects you from what is likely to be an error.  Yes, it means you have to do a little extra typing to define everything before using it.  But, to me at least, it's worth the effort to have that protection.  [Stata takes the protective approach in many other contexts, like not letting you overwrite your data set without explicitly saying so.]  Of course, all of us try to be careful in our work.  But, at least in my field of public health, it is generally recognized that a system that relies on human vigilance to work correctly is a system designed to fail.
>
> Now, there are many Stata users who like not being forced to define a macro before using it; current default behavior works well for them.  So let's make it an option that the user can set to allow or disallow references to undefined macros.  And since there are probably a lot of ado files out there that rely on undefined macros' being legal empty strings, it probably should be automatically over-ridden when the code was written under an earlier version.
>
> By the way, given that Stata 12 came out about a year and a half ago, I would guess that release of Stata 13 is about 6 months away.  I would also guess that the features of Stata 13 were decided a while ago and are already frozen.  So aren't we really talking about a wishlist for Stata 14?

*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/faqs/resources/statalist-faq/
*   http://www.ats.ucla.edu/stat/stata/


© Copyright 1996–2018 StataCorp LLC   |   Terms of use   |   Privacy   |   Contact us   |   Site index