Macro list operations with globals

[Geoff Clarke]

Apologies, I must be missing something basic, but I do not understand why the union of two globals would produce an empty set. I must be referencing them incorrectly.

Feel free to curtly point me to the correct piece of documentation.

The do file

local alice "Well"
local bob "Then"
local charlie : list alice | bob
di "`charlie'"

global dean "Well"
global eliza "Then"
local frank : list dean | eliza
di "`frank'"

The output

. local alice "Well"

. local bob "Then"

. local charlie : list alice | bob

. di "`charlie'"
Well Then

.
. global dean "Well"

. global eliza "Then"

. local frank : list dean | eliza

. di "`frank'"

[Clyde Schechter]

The macro list functions assume that the names of the macros that appear after the colon are local macros. Since you don't define any local macros dean and eliza, they are interpreted as empty, and their union is also empty.

Bearing in mind that there is seldom good reason to use global macros in the first place and they are inherently unsafe, this is a sensible default.

Nevertheless, assuming you are in one of those rare situations where the use of global macros is appropriate, you can override the default by running:

local frank: list global(dean) | global(eliza)

[Nick Cox]

Note that this follows also from the fact that globals and locals can have the same name. So what you were expecting could raise a clash between globals and locals with the same name.

[Geoff Clarke]

Thanks! I understand the warning about globals. A bit of suboptimal programming style that I'll try to eliminate.

[Jesse Wursten]

Bearing in mind that there is seldom good reason to use global macros in the first place and they are inherently unsafe, this is a sensible default.

They are unsafe, but remarkably convenient. At least my personal experience with locals has been endless frustration (you can't run parts of code unless all the locals referenced are defined in that part) whereas the amount of times I've been misled by globals can be counted on one hand. Of course, your mileage may vary...

[Clyde Schechter]

I agree that being misled by globals doesn't happen very often, particularly if you exercise some care in choosing their names to reduce the likelihood of conflicts. But my strong aversion to them relates to the traumatic experiences I have had with trying to find and fix the bugs they create when things do go wrong. It is nightmarish trying to fix problems that arise in one place when the source of the problem is a conflict with something in some other file that you might not even realize is being used! When you use globals you are taking responsibility for knowing what global macros are used in all the programs you call in your code. Since most of those will be programs you have not written yourself, and many of them will be programs that are called by something you called rather than called directly by you, this is a big ask. I've gone down that road a few times in the past (not in Stata but in other contexts with constructs equivalent to global macros) and it's really awful.

As for the frustration about running parts of code unless the locals are also defined there, I think that problem has been largely eliminated now that the do-file editor makes it really easy to comment out the intervening portions of the code.