Section 7.4. Variable Names

7.4. Variable Names

The name of a variable must begin with a letter or underscore and must consist entirely of alphanumeric or underscore characters. 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_].

7.4.1. Case-Insensitivity of Variable Names

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 (that is, during decompilation) so that their case matches the first usage of the name:

 set myVar to 5 set myVar to myVar + 1 

This phenomenon suggests a trick that can help you spot mistakes: when you first define a variable, use an uppercase letter in its letter; elsewhere, never use an uppercase letter in a variable name. Then, after compilation, any variable name without an uppercase letter must be a mistake. For example, here's some code that I typed following these rules, before compilation:

 set myVar to 5 set mybar to myvar + 1 

Here's the same code after compilation:

 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.

But this trick is not easy to implement, and it's unreliable because you still might not spot the mistake. The truth is that incorrect variable names are a notorious cause of bugs in scripts, and can be extremely difficult to track down. The real problem is that AppleScript doesn't require you to declare your variables (and unlike Perl with its strict mode, it doesn't let you require it to require you). In my view, this is one of many instances where a feature probably intended to make the language easier actually makes it harder.

7.4.2. Memory of Variable Names

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 "Maintenance of State" in Chapter 3.) Suppose you compile this script:

 set avariable to 7 

You then change the script to give the variable name inner capitalization:

 set aVariable to 7 

When you compile, AppleScript removes the inner capitalization!

 set avariable to 7 

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

In Script Editor, this rule washes over to other scripts that you edit during the same session! To see this, start up Script Editor and compile this script:

 set myvar to 7 

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

 set myVar to 7 

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

 set myvar to 7 

This is because Script Editor uses just one AppleScript scripting component instance per session (that is, until you quit Script Editor). 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. 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. Furthermore, Script Debugger uses a different AppleScript scripting component for each script window, so variable names in different scripts don't affect one another.

7.4.3. Variable Names and Vertical Bars

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 effect 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 term already in use. 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 terms that are in use." But it's not so easy. Lots of terms are in use (by AppleScript, by scripting additions, and by the application you're targeting), you can't possibly know what they are, and conflicts are all too easy to stumble into. The use of pipes is a common way to stumble back out. (See "Extensibility and Its Perils" in Chapter 4, and "Terminology Clash" in Chapter 20.)