7.3 Variable Names

The name of a variable must begin with a letter or underscore and must consist entirely of alphanumeric characters or underscore. So a variable name must begin with a character in the character set [a-zA-Z_] and must consist entirely of characters in the character set [a-zA-Z0-9_].

Variable names are case-insensitive at compile time. That means the following code will compile and run:

set myVar to 5
set myvar to myvar + 1

AppleScript assumes that myvar in the second line is the same variable as myVar in the first line. Furthermore, as a reflection of this assumption, AppleScript rewrites the variable names after compilation so that their case matches the first usage of the name:

set myVar to 5
set myVar to myVar + 1

This suggests a trick that can help you spot undeclared variables: in your declarations, use an uppercase letter somewhere in every variable name; elsewhere, never use an uppercase letter in a variable name. Then, after compilation, any variable name without an uppercase letter must be an undeclared variable. For example, here's some code that I typed following these rules, after compilation:

local myVar
set myVar to 5
set mybar to myVar + 1

In that code I have accidentally created and set the value of an unwanted variable mybar in the last line. I meant to say myvar, but I mistyped it. This won't cause AppleScript to generate any error, and the script will misbehave. The chances that I will spot my mistake are increased by my use of the case trick.

Once a script has been compiled for the first time, its variable names are remembered as they appear at that moment. (Recall that AppleScript has a memory. See Section 4.2.4.) Suppose you compile this script:

local avariable
set avariable to 7

You then change your mind and decide to use the inner capitalization trick, so you edit the script to give the variable names inner capitalization:

local aVariable
set aVariable to 7

When you compile, you find your efforts are in vain; AppleScript removes the inner capitalization!

local avariable
set avariable to 7

The reason is that when AppleScript first saw the variable name avariable—the first occurrence during the first compilation of the script—it had no capitalization, and that's how the name is remembered from then on.

What's more, this rule washes over to other scripts that you edit during the same session! To see this, start up your script editor program and compile this script:

set myvar to 7

Now open a new, different window and compile this script:

local myVar
set myVar to 7

Your variable names are changed in this second script! It ends up looking like this:

local myvar
set myvar to 7

This bizarre behavior is caused by the combination of two facts: variable names are remembered at global level in the AppleScript scripting component, and there is just one AppleScript scripting component instance per script editor session. (You did reread Section 4.2.4, didn't you?) This instance is shared by all the scripts you compile during that session, so the variable names in one script affect the variable names in another. This phenomenon persists until you quit the Script Editor program. Two different applications don't share the same AppleScript scripting component instance, though, so your variable names in Script Editor do not affect your variable names in Script Debugger at the same moment.

You can force an illegal variable name to be legal by surrounding it with vertical bars, also known as "pipes" (|). So, for example:

set |1| to 2
if |1| is 2 then
        display dialog "The laws of logic are suspended."
end if

The laws of logic aren't really suspended; 1 and 2 have not become the same number. A variable named "1" has been assigned the value 2, that's all. This device is good also for variable names in languages other than English:

set |monZéro| to 0

or for spaces in a variable name:

set |my big long variable name with spaces| to 7

A variable name surrounded by pipes is case-sensitive. This script will compile, but it won't run:

set |MyVar| to 5
set |MyVar| to |Myvar| + 1 -- error

The reason is that |Myvar| is not the same variable as |MyVar| and has never been given a value, so its value can't be fetched. AppleScript will not touch the case of names in pipes after compilation.

A variable name surrounded by pipes may include a backslash as an "escape" character. The legal escape expressions in this context are \n, \r, \t, \|, and \\.

The real meaning of pipes is to tell AppleScript to suspend its compile-time parsing rules and turn what's inside the pipes into a token. The main reason this is genuinely useful is to avoid a conflict between a token name and a reserved word. For example:

set |is| to "ought"

You couldn't do that without the pipes, because is is a reserved word, a part of the AppleScript language.

Now, you might say: "So what? I'll never need to worry about that; I just won't use any names that conflict with reserved words." But even though you might not use such names, some entity with which you need to communicate might do so. For example, some unwary developer could use a reserved word as part of the vocabulary defined by a scriptable application (even though they're not supposed to), and you would then need pipes in order to use that word to talk to the application. (See Section 19.2.)