creating variable lists using local macros - empty macros

[Isabel Lechner]

Dear Stata users

I created a list of variables using the following command:

local chemie mpi spi (create a local macro with the name chemie, containing the two variables mpi and spi)

I then do a regression analysis, using the following command:

regress pkd `chemie`

I'm working with a do-file, and it only works if I execute both commands at the very same time (mark both lines, execute once). As soon as I execute them one by one (execute the two lines after each other) the local macro stays empty.
Is there any way that Stata will remember my local macros in the case I'm not executing both commands at the very same time?
I'm acutually building some models, that's why I would like to create a local macro at the beginning of the script to create a few variable lists, and then later try different model approaches. Now it doesn't make any sense if I have to redefine the macros every time before I'm running my models, especially in the process of model building.

Is there maybe another useful approach?

I'm using Stata 12.0

Many thanks,
Isabel

[Nick Cox]

That's what local means. Local macros are only visible within the same chunk of code. But the problem suggests the solution: try to avoid running code in very small chunks, which is what leads to this problem. Why would you want to do that?

See also help include for another solution.

[FernandoRios]

Well, if there is a way to make Stata remember locals, i havent found it yet.
I think, the whole purpose of a local in a program, however, is memory efficiency, so the information is not "permanently: stored in memory.
Perhaps you could give a try to global, which remains in memory, and at least for your example. should work with no problem.
Best
Fernando

[Jeph Herrin]

To add to the other advice, if you execute your lines from the do-file editor, you can select multiple lines at once to execute; if you select the -local- definition, the local will be "remembered" for the subsequent lines of code.

[Clyde Schechter]

Several thoughts:

I don't think that the purpose of a local in a program is memory efficiency. Rather the whole point of a local macro is that it holds scope only in the block of code where it is defined: that way you can choose whatever macro name you want without having to worry that it clashes with a macro of the same name that is used in, say, a program called by your do/ado-file, or with a macro in a higher-level do/ado-file that called yours.

I think Nick's suggestion to look at -include- is the best way to resolve the problem raised by the original poster. I can readily understand why the original poster might want to run models one at a time while doing data exploration, or while testing code, particularly if the analyses are time consuming (think melogit with 4 levels of random effects!). On the other hand, if the analyses really are just -regress-, it's probably just easier to run them all, as they take only an imperceptible amount of time.

[Konrad Zdeb]

Well, if there is a way to make Stata remember locals, i havent found it yet.

Why stick with locals at any price? If you keep on calling them all the time in different circumstances would it be more convenient to redefine those macros as global?

[Clyde Schechter]

@Konrad Zdeb. If you are working in a very simple, limited context, using global macros may be the appropriate solution. The problem is that global macros are inherently unsafe. At a minimum, you need to run -macro dir- first to make sure there isn't already a global macro with the name you plan to use. You also need to worry that some program you call (or some program that a program you call calls, etc.) seeks to use the same name. Once a name clash arises the side-effects can be bizarre and nearly impossible to track down and fix.

Really, if you are using a macro just to hold a list of variables you want to work with in your do-file, there is no reason that other code should know about them or, worse, be able to inadvertently change them. When there is actual need to pass the information to a program, arguments and options serve that purpose and you can explicitly pass them.

For the kind of situation that the original poster mentioned, the #include workaround is easy and completely safe.

[Clyde Schechter]

One more thought for the original poster's problem. If there are a bunch of analyses to be done and you want to do them one at a time, relying on a single set of local macros defined at the top, you can sequentially comment out the ones you're finished with using /* */.