The word "script," like a number of terms associated with AppleScript, is liable to be tossed rather loosely about in a bewildering variety of senses. Some of its meanings are technically important and therefore indispensable, so it will help if we pause to clarify its chief uses explicitly.
3.3.1. Script as Drive
To "script" an application is to automate it, to drive it, to target it. People say, "I'd like to script the Finder to rename some files automatically." There is an implication that the Finder already has the power to do things to files, and that we are merely taking advantage of this power by dictating programmatically a sequence of actions that the Finder should take. This, after all, is why the Finder is said to be "scriptable" in the first place.
This sense of "script" is formalized in the way some sources define a "scripting language." This quotation comes from the ECMAScript Language Specification (http://www.ecma-international.org/publications/standards/ECMA-262.htm):
That is a perfect description of AppleScript. It has few powers of its own; it is meant primarily for controlling the powers of existing applications.
3.3.2. Script as Program
The preceding quotation from ECMA continues:
This leap is common enough, but in my view it is unwarranted. Most languages commonly referred to as scripting languages are full-fledged programming languages, and make no particular concession to informality or inexperience. There is arguably nothing easy, and certainly nothing simplistic, about Tcl, Perl, or Scheme. As far as ease of use is concerned, any distinction between a scripting language and a programming language is a distinction without a difference.
Unfortunately this false distinction has played a major role in the history of AppleScript, especially in Apple's own official propaganda. Even today, Apple's main web page on AppleScript (http://www.apple.com/applescript/) talks about how you "write script files" that "make decisions"along with many other such extraordinary verbal contortions clearly intended to avoid using the word "program" (which never appears).
The term "script" has thus ended up as an acceptable synonym for the politically incorrect "program." Ostensibly, you do not program with AppleScript; you script with it. What you write are not programs; they're scripts. You're not a programmer; you're a scripter. This, I feel, is just silly. AppleScript is a programming language (and, I happen to think, not a particularly easy one). You are a programmer, and you will write programs with AppleScript.
3.3.3. Script as Script Object
Many AppleScript programs that you write or read will contain the term script used to demarcate part of their code. Here's an example:
script myScript display dialog "Hello from " & (get my name) & "!" end script run myScript dialog says: Hello from myScript!
The first three lines are a block of code starting with the word script. Such a section of code is often called a script object.
In fact, it turns out that an AppleScript program as a whole is itself a script object. This may sound confusing, but in fact it's quite a cool and sophisticated aspect of AppleScript. Thus it is reasonable and rigorously correct to speak of an AppleScript program as a whole as a script, not as a way of avoiding the fact that it is a program, but as a way of expressing its ontological status within the world of AppleScript. As you'll learn later, a script as a whole and a script object within a script have exactly the same ontological status. The script-as-a-whole does have some special features of its own, because it is the ultimate container of any other script objects; it is the top-level script object. But it is not different in kind from script objects that it may contain. (We'll fully explore the details of script objects later in the book, especially in Chapter 8.)
3.3.4. Script as Scripting Component Operand
The term "script" also refers in a completely technical and rigorous sense to a unit of operation between an application that asks for some AppleScript code to be compiled or executed and the scripting component that does the actual work. When such a program sends the scripting component a bunch of text for compilation, as in Figure 3-2, that bunch of text is assigned an identifying number. This number points to the code that is being remembered by the scripting component, and is called its script ID. It is by this arrangement that the application and the scripting component can continue to talk about the code while it persists over time, as described earlier in this chapter ("Maintenance of State"). The code itself, the thing being remembered by the scripting component, is thus technically a script, because that's what the scripting component itself calls it. A script is a kind of entity that the scripting component holds on to and can perform various operations on, such as compiling it or executing it.
3.3.5. Script as File
The individual code file is an important and meaningful unit in AppleScript. Unlike some programming environments, where multiple files are assembled through a "make" or some other build process into a separate object file embodying the complete program, with AppleScript the individual file is the complete program. An AppleScript program and the file containing it are thus coterminous. But, as we have just seen, an AppleScript program is a script, because it is a script object. In fact, it will turn out that any script object can be saved as a file (see "Compiled Script Files as Script Objects" in Chapter 8). Just the other way around, any saved compiled script file can be handed to an AppleScript scripting component (as a script) and executed. There is thus a natural and meaningful correspondence between scripts and files, and it makes sense to speak of the file in which your code is saved as itself a script. We see this use of "script" in many places. The script file icon in the Finder seems to represent the script. One says, "Double-click the script to open it in the Script Editor." The Script Editor itself speaks of saving your code as a script.