Re: st: Wishlist for Stata 13

[William Buchanan <william@williambuchanan.net>]

On a note unrelated to Clyde's suggestion, one thing I was thinking of was possibly exported SEM graphics using xypic for inclusion in LaTeX documents.  Depending on the code underlying the SEM graphics, it might be something that users could write (e.g., translating the Stata code to make sense in xypic) as well, and it could be possible if there is any documentation related to the SEM graphics that the folks at StataCorp could direct us towards.

Thanks again,
Billy

Sent from my iPhone

On Jan 10, 2013, at 9:48, Nick Cox <njcoxstata@gmail.com> wrote:

> 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/

*
*   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/