Line break in do file | What I am I doing wrong?

[Girish Venkataraman]

Something very simple with renaming six variables in a do file. I cant understand why the /// is not working as I am expecting it to. Thought it helps breaks code across two lines. The do file stops here. See below if I am using the // and /// properly


. **# RT LABS and PET*********************************************** **********
. rename (ecogpsattransfm rtbaselinecreatininet rtbaselinealbumin ///
rtbaselinebilirubintotal rtbaselineancpmicliter rtplateletsbaselinepmiclitr) ///
(tsbecog rtsbcreat tsbalbm tsbblr tsbanc tsbplt) // Renaming with tsb transformation baseline prefix

( invalid name
r(198);

[William Lisowski]

Not sure what your problem is, this example works on Stata 17.0.

. ds, varwidth(30)
ecogpsattransfm              rtbaselinealbumin            rtbaselineancpmicliter
rtbaselinecreatininet        rtbaselinebilirubintotal     rtplateletsbaselinepmiclitr

. rename (ecogpsattransfm rtbaselinecreatininet rtbaselinealbumin ///
> rtbaselinebilirubintotal rtbaselineancpmicliter rtplateletsbaselinepmiclitr) ///
> (tsbecog rtsbcreat tsbalbm tsbblr tsbanc tsbplt) // Renaming with tsb transformation baseline 
> prefix 

. ds
tsbecog    rtsbcreat  tsbalbm    tsbblr     tsbanc     tsbplt

[daniel klein]

The example will not work in Stata 11 or earlier; the rename command was extended to handle multiple variables in Stata 12.

[William Lisowski]

To Daniel Klein's excellent visit to the past, let me add that I have been trying to duplicate the error message shown in post #1, and the only way I have been able to do is is by running under version control:

version 11: rename ( ...

In an earlier topic you mentioned running a command in your copy of Stata 11. On Statalist, we assume in the absence of information to the contrary that you are using the latest release of Stata that is available at the time, as discussed in the Statalist FAQ linked to from the top of each page on Statalist. When your problem requires the use of Stata 11 you should disclose that in your initial post when creating a topic. Or consider replacing that version of Stata with a newer version, since moving between Stata 17 (which you also indicated you have access to) and Stata 11 will constantly require you to ask yourself if the Stata 11 problem also exists in Stata 17. Or put in another direction, when code fails on Stata 11 you should use e.g.

help rename

in Stata 11 to refresh your understanding of the command syntax in the older version.

[daniel klein]

have been trying to duplicate the error message shown in post #1, and the only way I have been able to do is is by running under version control:

version 11: rename ( ...

That is interesting both technically and conceptually. Technically, this implies that under version control, Stata calls its built-in _rename (the old rename) instead of rename.ado. Conceptually, it is interesting because I think this is unintended behavior. Here is why. First, version control is generally not meant to set back or disable improvements. Second, the behavior is not documented in the version changes (see help version). Third, we find the following comment in rename.ado:

This routine is included so that the command implemented here
can displace the old -rename- command without sacrificing
performance for those executing 10,000s of -rename- commands
in tight loops.

All of the above indicates that you should not be able to reproduce the error in Stata 12 or later.

[Girish Venkataraman]

To Daniel Klein's excellent visit to the past, let me add that I have been trying to duplicate the error message shown in post #1, and the only way I have been able to do is is by running under version control:

version 11: rename ( ...

In an earlier topic you mentioned running a command in your copy of Stata 11. On Statalist, we assume in the absence of information to the contrary that you are using the latest release of Stata that is available at the time, as discussed in the Statalist FAQ linked to from the top of each page on Statalist. When your problem requires the use of Stata 11 you should disclose that in your initial post when creating a topic. Or consider replacing that version of Stata with a newer version, since moving between Stata 17 (which you also indicated you have access to) and Stata 11 will constantly require you to ask yourself if the Stata 11 problem also exists in Stata 17. Or put in another direction, when code fails on Stata 11 you should use e.g.

help rename

in Stata 11 to refresh your understanding of the command syntax in the older version.

Thanks much William. I did have Stata 11 earlier as you said (that quite some memory!!!). I did have the do file start off by making it version 11 compatible. I would never have guessed that the reason. I can easily get rid of that part and replace with v17.

[daniel klein]

I did have Stata 11 earlier as you said (that quite some memory!!!).

Memory is not necessarily required.

help whatsnew11to12

Obviously, it helps if you know what you are looking for so you will not have to search through all the whatsnew files. I am just pointing out that all the major changes are, in principle, thoroughly documented.


Anyway, and more importantly, I have two comments on

I did have the do file start off by making it version 11 compatible. I would never have guessed that the reason. I can easily get rid of that part and replace with v17.

First, I have noted in #5 that I do not think that setting the version to 11 should backdate rename. There should not be a problem with your code in the first place. Second, setting the version to 11 does not at all guarantee that your file will be compatible with version 11. The reason is exactly what I have pointed out: improvements are typically not undone. For example,

version 11
frame create foo

will not cause any problems in Stata 16 or later but will exit with error in Stata versions before 16 because the frame command did not even exist when these versions were released. Long story short: if you want to ensure that your code is compatible with earlier versions of Stata, you need to run it with a physical copy of those older versions.

[Girish Venkataraman]

Memory is not necessarily required.

help whatsnew11to12

Obviously, it helps if you know what you are looking for so you will not have to search through all the whatsnew files. I am just pointing out that all the major changes are, in principle, thoroughly documented.


Anyway, and more importantly, I have two comments on



First, I have noted in #5 that I do not think that setting the version to 11 should backdate rename. There should not be a problem with your code in the first place. Second, setting the version to 11 does not at all guarantee that your file will be compatible with version 11. The reason is exactly what I have pointed out: improvements are typically not undone. For example,

version 11
frame create foo

will not cause any problems in Stata 16 or later but will exit with error in Stata versions before 16 because the frame command did not even exist when these versions were released. Long story short: if you want to ensure that your code is compatible with earlier versions of Stata, you need to run it with a physical copy of those older versions.

I will go over the documentation. Daniel. You are right. Knowing to the search the right thing is key. Will go over that help.

[William Lisowski]

My understanding of the purpose of version differs from that of daniel klein in his posts above, and I do not believe that setting the version to 11 should not cause rename to reject the newer syntax.

From the output of help version we read the following, where I have highlighted in red my particular interest.

Description

    At the top of every do-file or program that you create, type

        version 17

    That single step ensures that your do-file or program will continue to run in
    all future versions of Stata, even if that future version has changes in the
    syntax of some of the commands or programming constructs that you use in your
    do-file or program.  The few other ways to use Description

    At the top of every do-file or program that you create, type

        version 17

    That single step ensures that your do-file or program will continue to run in
    all future versions of Stata, even if that future version has changes in the
    syntax of some of the commands or programming constructs that you use in your
    do-file or program.  The few other ways to use version are in support of this
    functionality and are unimportant by comparison.

And further down

Remarks

    Stata is continually improving, and sometimes that means that commands or
    language elements in the interpreter need to change.  version ensures that
    do-files, ado-files, and other programs continue to work.  They will continue
    to work in all future versions of Stata regardless of the version of Stata in
    which they were written.

    version # sets the interpretation of all language elements and commands to be
    the same as it was in version #.  All do-files, ado-files, and other programs
    written for the current version of Stata should include version 17 as the first
    executable statement.

I interpret this to mean that the focus of the version command is to ensure that do-files that include the version command at the top do not need to be rewritten to parse correctly and run in future versions of Stata where the command syntax has changed. Stata will always parse the do-file following the syntax rules of the specified version. In some cases this is done by writing the updated command to follow different syntax rules depending on the version under which it is run. In other cases it is done by having the updated command run the actual code from the older version of Stata, as is apparently the case for rename.

I infer that that is the expected behavior of the version prefix: to interpret the command following the syntactical rules in effect for the command in the specified version. I am guessing that prior to version 12

rename (a) (b)

threw the syntax syntax error shown in post #1, and if so, it is not inappropriate that

version 11: rename (a) (b)

also throws the same syntax error.

I want to close by explicitly agreeing with Daniel's important advice for those writing code that is intended to be run on older versions:

if you want to ensure that your code is compatible with earlier versions of Stata, you need to run it with a physical copy of those older versions

[daniel klein]

I appreciate William Lisowski's comments. I also see how the highlighted parts can be interpreted the way he does. I still believe that version does not, generally, undo improvements. Two examples that come to mind

sysuse auto
version 9 : label values price mpg foo

should yield an invalid syntax error, because, before Stata 10, the label values command would only accept one variable name (i.e., two arguments). Also,

version 10 : merge 1:m ...

should yield a syntax error, because merge did not know what to make of 1:m in versions before 11. I am pretty confident that we can find many more examples.

EDIT: No need to guess. Type

version # : any_command_not_written_before_#

I predict that you will get invalid syntax errors for less than one percent of all commands. Clearly, rename appears to be the exception rather than the rule here.


More generally, I interpret the help file to imply that the version command ensures valid syntax that does not throw errors now not throw errors in future versions. It does not guarantee that invalid syntax will remain invalid. When you think about it, that would probably be next to impossible without keeping all (ado-)files and all old internal code around in all future versions of Stata. EDIT 2: That would also go against the philosophy not to reinstate bugs.

[William Lisowski]

More generally, I interpret the help file to imply that the version command ensures valid syntax that does not throw errors now not throw errors in future versions. It does not guarantee that invalid syntax will remain invalid.

I agree, but my point was that it also does not guarantee that newly-valid syntax will become valid in older versions.

. sysuse auto, clear
(1978 automobile data)

. version 17: table foreign, statistic(count price)

-----------------------------------------
           |  Number of nonmissing values
-----------+-----------------------------
Car origin |                             
  Domestic |                           52
  Foreign  |                           22
  Total    |                           74
-----------------------------------------

. version 16: table foreign, statistic(count price)
option statistic() not allowed
r(198);

. version 16: table foreign, contents(count price)

----------------------
Car       |
origin    |   N(price)
----------+-----------
 Domestic |         52
  Foreign |         22
----------------------

. version 17: table foreign, contents(count price)
option contents() not allowed since Stata 17; see help table for updated syntax
r(198);

.

[daniel klein]

I think, we basically agree. The inconsistencies we have shown here suggest that there is room for interpretation when deciding on the details of what exactly version does for a specific command. However, contrary to the behavior of rename, the (old) behavior of table is documented under "Summary of version changes" in the help for version.

The main take-away message is: specify the version that you are actually using when writing your files. That is, use version as it is supposed to be used and as recommended in the help file.

[Girish Venkataraman]

Thanks William Lisowski and daniel klein I sure learnt a bit seeing your discussion. Explains the scope, purpose and usage of version.